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(57) A system and method for performing S RNS re- 
location in a communication system transmits radio re- 
source information including a ciphering parameter from 
a source RNC to a target RNC, modifies the ciphering 
parameter to coincide with a deciphering parameter 
which a user terminal uses when out-of -sequence data 
is received, ciphers a data unit based on the modified 
ciphering parameter, and transmits the ciphered data 
unit from the target RNC to the user terminal. The meth- 
od may be modified to operate in UM mode or Am mode 
and to transmit data over one of several radio bearers. 
In accordance with another embodiment, the system 
and method transmits radio resource information from 
a source RNC to a target RNC and then transmits a data 
unit from the target RNC to a user terminal. In this case, 
the data unit including a transmission sequence number 
which consecutively follows a transmission sequence 
unmber of a data unit last transmitted from the source 
RNC to the uer terminal. In accordance with another em- 
bodiment, the system and method resets ciphering and 
state variables in a target RNC and then transmits a 
message instructing a user terminal to reset a decipher- 
ing and state variables to the same or similar values . All 
the embodiments are advantageous because they en- 
sure successful communications will take place be- 
tween the target RNC and user terminal after a serving 
radio network sub-system relocation procedure is per- 
formed. 
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Description 

BACKGROUND OF THE INVENTION 

1. Field of the invention 

[0001] This invention generally relates to wireless 
communication systems, and more particularly to a sys- 
tem and method for performing a serving radio network 
sub-system (SRNS) relocation procedure in a commu- 
nications system. 

2. Background of the Relate Art 

[0002] A universal mobile telecommunications sys- 
tem (UMTS) is a third generation mobile communication 
system that has evolved from a standard known as Glo- 
bal System for Mobile communications (GSM). This 
standard is a European standard which aims to provide 
an improved mobile communication service based on a 
GSM core network and wideband code division multiple 
access (W-CDMA) technology. In December, 1998, the 
ETSI of Europe, the ARIB/TTC of Japan, the T1 of the 
United States, and the TTA of Korea formed a Third 
Generation Partnership Project (3GPP) for the purpose 
ol creating a specification for standardizing the UMTS. 
[0003] The work towards standardizing the UMTS 
performed by the 3GPP has resulted in the formation of 
five technical specification groups (TSG), each of which 
is directed to forming network elements having inde- 
pendent operations. More specifically, each TSG devel- 
ops, approves, and manages a standard specification 
in a related region. Among them, a radio access network 
(RAN) group (TSG- RAN) develops a specification for 
the function, items desired, and interface of a UMTS ter- 
restrial radio access network (UTRAN), which is a new 
RAN for supporting a W-CDMA access technology in 
the UMTS. 

[0004] The TSG-RAN group includes a plenary group 
and four working groups. Working group 1 (WG1) de- 
velops a specification for a physical layer (a first layer). 
Working group 2 (WG2) specifies the functions of a data 
link layer (a second layer) and a network layer (a third 
layer). Working group 3 (WG3) defines a specification 
for an interface among a base station in the UTRAN, a 
radio network controller (RNC), and a core network. Fi- 
nally, Working group 4 (WG4) discusses terms desired 
for a radio link performance and items desired for radio 
resource management. 

[0005] Figure 1 shows a structure of a 3GPP UTRAN 
to which the present invention may be applied. This 
UTRAN includes one or more radio network sub-sys- 
tems (RNS). Each RNS includes an RNC and one or 
more Nodes B (e.g., a base station) managed by the 
RNCs. RNCs are connected to a mobile switching cent- 
er (MSC) which performs line exchange communica- 
tions with the GSM network. The RNCs are also con- 
nected to a serving general packet radio service support 



node (SGSN) which performs packet exchange commu- 
nications with a general packet radio service (GPRS) 
network. 

[0006] Nodes B are managed by the RNCs, receive 
information sent by the physical layer of a terminal (e. 
g. t mobile station, user equipment and/or subscriber 
unit) through an uplink, and transmit data to a terminal 
through a downlink. Nodes B, thus, operate as access 
points of the UTRAN for the terminal. 
[0007] The RNCs perform functions which Include as- 
signing and managing radio resources. An RNC that di- 
rectly manages a Node B is referred to as a control RNC 
(CRNC). The CRNC manages common radio resourc- 
es. A serving RNC (SRNC), on the other hand, manages 
dedicated radio resources assigned to the respective 
terminals. The CRNC can be the same as the SRNC. 
However, when the terminal deviates from the region of 
the SRNC and moves to the region of another RNC, the 
CRNC can be different from the SRNC. Because the 
physical positions of various elements in the UMTS net- 
work can vary, an interlace for connecting the elements 
is necessary. Nodes B and the RNCs are connected to 
each other by an lub interface. Two RNCs are connected 
to each other by an lur interface. An interface between 
the RNC and a core network is referred to as lu. 
[0008] Services provided to the UE may generally be 
classified into circuit-switching services and packet- 
switching services. A voice telephone service may be 
included in the circuit-switching service and a Web- 
browsing service may be included in a packet-switching 
service through an Internet connection. The circuit- 
switching service is connected to an MSC of the core 
network, and this MSC is connected to a gateway mobile 
switching center (GMSC) for communicating with one or 
more external networks. The GMSC manages the con- 
nections between the MSC and the external networks. 
[0009] The packet-switching service is connected to 
a serving general packet radio service (GPRS) support 
node (SGSN), this node is connected to a gateway 
GPRS support node (GGSN) of the core network. The 
SGSN communicates packets between the SRNC and 
GGSN, and the GGSN manages connections between 
the SGSN and another packet-switching network such 
as the Internet. 

[0010] A variety of interfaces are provided for per- 
forming mutual data exchanges between these network 
components. An interface between an RNC and the 
core network is known as an lu interface. When the lu 
is connected to the packet-switching domain, it is called 
an lu PS interface, and when the lu is connected to the 
circuit-switching domain it is called a lu CS interface. 
[0011] Figure 2 shows a structure of a radio access 
interface protocol between a terminal which operates 
based on a 3GPP RAN specification and a UTRAN. The 
radio access interface protocol is horizontally formed of 
a physical layer (PHY), a data link layer, and a network 
layer and is vertically divided into a control plane for 
transmitting control information and a user plane for 
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transmitting data information. The user plane is a region 
to which traffic information of a'user such as voice or an 
IP packet is transmitted. The control plane is a region to 
which control information such as an interface of a net- 
work or maintenance and management of a call is trans- s 
mitted. 

[001 2] In Figure 2, protocol layers can be divided into 
a first layer (LI), a second layer (12), and a third layer 
(L3) based on three lower layers of an open system in- 
terconnection (OS I) standard model well known in a to 
communication system. The first layer (L1) operates as 
a physical layer (PHY) for a radio interface and is con- 
nected to an upper medium access control (MAC) layer 
through one or more transport channels. The physical 
layer transmits data delivered to the physical layer ts 
(PHY) through a transport channel to a receiver using 
various coding and modulating methods suitable for ra- 
dio circumstances. The transport channel between the 
-physical layer (PHY) and the MAC layer is divided into 
a dedicated transport channel and a common transport 20 
channel based on whether it is exclusively used by a 
single terminal or shared by several terminals. 
[0013] The second layer L2 operates as a data link 
layer and lets various terminals share the radio resourc- 
es of a W-CDMA network. The second layer 12 is divid- 25 
ed into the MAC layer, a radio link control (RLC) layer, 
a packet data convergence protocol (PDCP) layer, and 
a broadcast/multicast control (BMC) layer. 
[0014] The MAC layer delivers data through an appro- 
priate mapping relationship between a logical channel so 
and a transport channel. The logical channels connect 
an upper layer to the MAC layer. Various logical chan- 
nels are provided based on the kind of transmitted in- 
formation. In general, when information of the control 
plane is transmitted, a control channel is used. When 35 
information of the user plane is transmitted, a traffic 
channel is used. The MAC layer is divided two sub-lay- 
ers according to performed functions. The two sub-lay- 
ers are a MAC-d sub-layer that is positioned in the 
SRNC and manages the dedicated transport channel *o 
and a MAC-c/sh sub-layer that is positioned in the 
CRNC and manages the common transport channel. 
[0015] The RLC layer forms an appropriate RLC pro- 
tocol data unit (PDU) suitable for transmission by the 
segmentation and concatenation functions of an RLC *5 
service data unit (SDU) received from an upper layer. 
The RLC layer also performs an automatic repeat re- 
quest (ARQ) function by which an RLC PDU lost during 
transmission is re-transmitted. The RLC layer operates 
in three modes: a transparent mode (TM), an unac- 50 
knowledged mode (UM), and an acknowledged mode 
(AM). The mode selected depends upon the method 
used to process the RLC SDU received from the upper 
layer. An RLC buffer stores the RLC SDUs or the RLC 
PDUs received from the upper layer. A more detailed 55 
explanation of the modes of operation of the RLC layer 
will follow. 

[0016] The packet data convergence protocol (PD- 



CP) layer is an upper layer of the RLC layer which allows 
data items to be transmitted through a network protocol 
such as IP.v4 or IP.v6. A header compression technique 
for compressing and transmitting the header information 
in a packet can be used for effective transmission of the 
IP packet. 

[0017] The broadcast/multicast control (BMC) layer 
allows a message to be transmitted from a cell broad- 
cast center (CBC) through the radio interface. The main 
function of the BMC layer is scheduling and transmitting 
a cell broadcast message to a terminal. In general, data 
is transmitted through the RLC layer operating in the un- 
acknowledged mode. 

[0018] The PDCP layer and the BMC layer are con- 
nected to the SGSN because a packet exchange meth- 
od is used, and are located only in the user plane be- 
cause they transmit only user data. Unlike the PDCP 
layer and the BMC layer, the RLC layer can be included 
in the user plane and the control plane according to a — 
layer connected to the upper layer. When the RLC layer 
belongs to the control plane, data is received from a ra- 
dio resource control (RRC) layer. 
[001 9] In general , the transmission service of user da- 
ta provided to the upper layer by the second layer (12) 
in the user plane is referred to as a radio bearer (RB). 
The transmission service of control information provided 
to the upper layer by the second layer (L2) in the control 
plane is referred to as a signaling radio bearer (SRB). 
As shown in Figure 2, a plurality of entities can exist in 
the RLC and PDCP layers. This is because a terminal 
has a plurality of RBs, and one or two RLC entities and 
only one PDCP entity are generally used for one RB. 
The entities of the RLC layer and the PDCP layer can 
perform an independent function in each layer. 
[0020] The RRC layer positioned in the lowest portion 
of the third layer (L3) is defined only in the control plane 
and controls the logical channels, the transport chan- 
nels, and the physical channels in relation to the setting, 
the re-setting, and the cancellation of the RBs. At this 
time, setting up the RB means processes of stipulating 
the characteristics of a protocol layer and a channel, 
which are required for providing a specific service, and 
setting the respective detailed parameters and opera- 
tion methods. It is possible to transmit control messages 
received from the upper layer through a RRC message. 
[0021] Operation of the radio bearer and the RLC lay- 
er will be now described in detail. As previously dis- 
cussed, a radio bearer (RB) is a transmission service 
which delivers user data in the user plane to an upper 
layer through the second layer L2. The transmission 
service which delivers control information in the control 
plane to the upper layer through the second layer L2 is 
defined as a signaling radio bearer <SRB). 
[0022] As previously noted, the RLC layer operates in 
one of three modes: transparent mode (TM), unac- 
knowledged mode (UM) : and acknowledged mode 
(AM). 

[0023] When operating in the TM mode, header infor- 
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mation is not added to the RLC SDU received from the 
upper layer, no sequence number is attached to the RLC 
PDU and data re-transmission is not performed. Also, 
though segmentation and reassembly of the RLC SDU 
are generally not performed, use of segmentation and 
reassembly when the radio bearer is set up is deter- 
mined in certain circumstances. 
[0024] When operating in UM mode, re-transmission 
of RLC PDUs is not performed even when a transmis- 
sion failure occurs. The receiver does not request re- 
transmission of data. Instead, a different approach is 
taken. In UM mode.the RLC layer constructs RLC PDUs 
by segmenting or concatenating RLC SDUs, and then 
attaching sequence numbers to the RLC PDUs. The re- 
ceiver can restore lost data based on the sequence 
numbers by a re* assembly procedure. 
[0025] When operating in the AM mode, re-transmis- 
sion is used to support error-free transmission in the fol- 
lowing manner. Status information corresponding to re- 
ceived RLC PDUs is transmitted from the receiver in the 
form of a Status Report. After receiving this report, the 
transmitter re-transmits unsuccessfully transmitted RLC 
PDUs. 

[0026] More specifically, in AM mode, the transmitter 
forms each RLC PDU from one or more RLC SDUs that 
have been received from an upper layer, and header in- 
formation, (e.g. sequence number and length indica- 
tors) are then attached. Since the si2e of an AM RLC 
PDU is fixed, the transmitter segments or concatenates 
one or more RLC SDUs to fit the PDU size. Then, the 
formed RLC PDU is stored in the transmission buffer. 
The stored RLC PDUs are sequentially delivered to the 
MAC layer at a rate controlled by the MAC layer. Since 
each RLC PDU has its own sequence number, the re- 
ceiver can check which RLC PDUs are successfully re- 
ceived and which are not. The receiver requests the re- 
transmission for the unsuccessfully received RLC PDUs 
to the transmitter by the Status Report. 
[0027] The AM retransmission procedure may be 
more clearly understood by the following example. If the 
sequence numbers of the received RLC PDUs are #23, 
#24, #25, #32, and #34, the receiver considers that RLC 
PDUs having the sequence numbers of #26 to #31 and 
#33 are lost during transmission. The receiver then 
sends a Status Report to the transmitter, and the trans- 
mitter checks the Status Report, and re-transmits the 
unsuccessfully transmitted RLC PDUs, i.e. #26 to #31 
and #33. 

[0028] Figure 3 shows the structure of an RLC PDU 
of AM or UM mode used in the RLC layer. The RLC PDU 
is comprised of a header and a payload. The header 
shown includes a sequence number and a length indi- 
cator. The sequence number is used as an identifier of 
the corresponding RLC PDU, and the length indicator 
indicates a boundary of the RLC SDU. The sequence 
numbers may be, for example, 7 (seven) bits for UM 
mode, and 12 (twelve) bits for AM mode. A 1 <one) bit 
E field msy be included to indicate whether the next field 
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is the length indicator or data. 
[0029] The length indicator is used to indicate the 
boundary of each RLC SDU ending within the RLC PDU. 
Therefore, the length indicator may not be present if the 

5 RLC SDU is not ended within the RLC PDU. The length 
indicator may also be used for other purposes. For ex- 
ample, the length indicator may be used as a padding 
indicator and/or a data start indicator. Padding is used 
to fill the whole RLC PDU when there is no RLC SDU to 

io be concatenated. The padding can have any value and 
the receiver and the sender disregard ft. When used as 
a data start indicator the length indicator may indicate 
that the RLC SDU begins in the beginning of the RLC 
PDU. 

15 [0030] The data start indicator is useful because it can 
prevent additional loss of data in the UM RLC. For ex- 
ample, assume that an RLC PDU of sequence number 
#4 is lost and an RLC PDU of sequence number #5 is 
received. Assume further that a hew RLC SDU begins 

so at the beginning of the PDU of sequence number #5 and 
ends within the PDU of sequence number #5. In this 
case, because the RLC SDU begins at the beginning ot 
the PDU of sequence number #5, the data start indicator 
is present at the header of the PDU of sequence number 

25 #5. But, if the data start indicator is not present, the re- 
ceiver RLC layer considers that only continued seg- 
ments of an RLC SDU contained in the RLC PDU of se- 
quence number #5 is received. In this case, the receiver 
discards the segments because the receiver thinks that 

30 the entire RLC SDU has not been received. 

[0031] Figure 4 shows an exemplary snapshot ot the 
status of an RLC buffer. As shown, the RLC PDUs are 
sequentially stored in the buffer and the successfully 
transmitted RLC PDUs are deleted from the buffer. As 

35 shown, the RLC layer uses state variables for managing 
the transmission of data using the RLC buffer. 
[0032] When operating in AM mode, the RLC layer us- 
es a state variable VT<S) to indicate the sequence 
number of the next RLC PDU to be transmitted for the 

40 first time, and a state variable VT(A) to indicate the se- 
quence number of the first RLC POU to be positively 
acknowledged by the receiver. The status of the buffer 
therefore indicates that the transmitter has transmitted 
RLC PDUs up to the PDU of sequence number of VT 

A 5 <S)-1 and has received positive acknowledgments up to 
the RLC PDU of VT(A)-1 from the receiver. 
[0033] When operating in the UM mode, the RLC lay- 
er uses a state variable VT<US) which is similar to VT 
<S) in AM mode. That is , VT(US) indicates the sequence 

50 number of the next RLC PDU to be transmitted. Howev- 
er, since there is no feedback from the receiver in UM 
mode, the state variable such as VT(A) is not defined. 
[0034] In both modes of operation, the initial value of 
the state variables may be set to 0 (zero). When the RLC 

55 layer is established, re-established. or reset, the state 
variables are set to this initial value. 
[0035] Returning now to radio communications proto- 
col shown in Figure 2, as previously indicated, the serv- 
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ice provided to the upper layer by the second layer L2 
in the control plane is defined as a signaling radio bearer 
(SRB). In operation, all RRC messages are exchanged 
between the terminal and the RNC through the signaling 
radio bearers SRBs. Using the RRC messages, the 
RNC can setup, modify, and release the radio bearers 
as needed in order to, for example, perform an SRNS 
relocation procedure, the details of which are described 
in greater detail below. 

[0036] Signaling radio bearer (SRB) characteristics 
as previously indicated are determined based on the 
mode of operation of the RLC and the type of logical 
channel used. A common control channel (CCCH) and 
dedicated control channel (DCCH) are used for the 
SRBs. CCCH is a logical channel carrying common con- 
trol information to several terminals. Since CCCH is a 
common logical channel, CCCH contains a UTRAN ra- 
dio network temporary identity (U-RNTI) to identify a 
specific terminal. The DCCH is a logicalchannel carry- 
ing dedicated control information to a specific terminal. 
[0037] The characteristics of each type of SRB are as 
follows. 

[0038] SRB0: For the uplink (UL) TM RLC is used, and 
for the downlink (DL)UM RLC is used. The logical chan- 
nel used for the SRB0 is CCCH. 
[0039] SRB1 : UM RLC is used, and the logical chan- 
nel is DCCH. 

[0040] SRB2: AM RLC is used, and the logical chan- 
nel is DCCH. The SRB2 carries only the messages gen- 
erated in the RRC layer. The SRB2 does not carry the 
upper layer messages. 

[0041] SRB3: AM RLC is used, and the logical chan- 
nel is DCCH. The SRB3 carries the messages received 
from the upper layer. 

[0042] SRB4: AM RLC is used., and the logical chan- 
nel is DCCH. The SRB4 also carries the messages re- 
ceived from the upper layer. The difference is that the 
SRB3 carries higher priority messages while the SRB4 
carries lower priority messages. 
[0043] SRB5-31: TM RLC is used, and the logical 
channel is DCCH. These SRBs are optionally used. 

SRNS Relocation Procedure 

[0044] Figure 5 is a diagram showing how a serving 
radio network sub-system (SRNS) procedure may be 
performed in a packet-switching based service domain. 
As shown, this procedure involves changing the RNS 
serving a user terminal from one RNS (or RNC) to an- 
other. When making this change, it is preferable to es- 
tablish the shortest route between the terminal and core 
network by changing the lu connection point. As is fur- 
ther shown, changing the lu connection point may in 
some instances cause the core network to switch from 
one SGSN (Old SGSN) to another (New SGSN) for pur- 
poses of performing communications with the user ter- 
minal. The S RNS relocation procedure may also be per- 
formed in the circuit-switching based service domain. 



[0045] An SRNS relocation procedure may be per- 
formed for at least the following reasons: 

• Connection Point Change : Relocation is performed 
5 to move the UTRAN to a CN connection point at the 

UTRAN side from the source RNC to the target 
RNC. 

Combined Hard Handover : Relocation is performed 
to move the UTRAN to a CN connection point at the 
UTRAN side from the source RNC to the target 
RNC, while performing a hard handover decided by 
the UTRAN. 

• Combined Cell/URA Update : Relocation is per- 
formed to move the UTRAN to the CN connection 
point at the UTRAN side from the source RNC to 
the target RNC, while performing a cell re-selection 
in the UTRAN. 

As will be discussed in greater detail, an SRNS reloca- 
tion procedure may require the use of different radio 
bearers depending upon the mode of operation of the 
RLC layer. 

[0046] SRNS relocation is usually classified into two 
cases: (1) terminal not involved case (Case I) and (2) 
terminal involved case (Case II). In Case I, SRNS relo- 
cation is initiated by a network's own decision and the 
terminal does not know whether the SRNS relocation is 
performed until the relocation procedure is terminated. 
In Case II, SRNS relocation is initiated as a result of the 
terminal's cell change (e.g., handover) request and the 
terminal knows the SRNS relocation at the beginning of 
the procedure. Though Cases I and II are different in 
that one is involved with the terminal and the other is 
not, the two cases have no substantial difference with 
respect to the SRNS relocation procedure. A more de- 
tailed explanation of this procedure now follows. 
[0047] During the SRNS relocation procedure, vari- 
ous signaling messages are exchanged between the 
terminal and one RNC, between the one RNC and an- 
other RNC, and between one of the RNCs and the core 
network. 

[0048] Figure 6 shows the exchange of signaling mes- 
sages that takes place between the terminal and core 
network in the SRNS relocation procedure of the UMTS. 
In this exchange, the "source RNC" is the RNC that 
plays the role of the SRNC before SRNS relocation and 
the "target RNC" is the RNC that plays the role of the 
SRNC after SRNS relocation. Likewise, the "old SGSN" 
is the SGSN before the relocation procedure and the 
"new SGSN" is the SGSN after the relocation proce- 
dure. Though the old and new SGSNs are shown to be 
different, the old SGSN and new SGSN may be the 
same in certain circumstances. Moreover, the proce- 
dure shown in Figure 6 may be applied to both Case I 
and Case II. 

[0049] The steps of the SRNS relocation procedure 
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will now be summarized. In an initial step, step 1, the 
source RNC decides to performan SRNS relocation. Ei- 
ther Case I or Case II may be used to trigger the relo- 
cation procedure. 

[0050] In step 2, the source RNC sends a Relocation s 
Required message to the old SGSN. The Relocation 
Required message includes information for performing, 
for example, relocation co-ordination, security function- 
ality, RRC protocol context information, and the terminal 
capabilities. 

[0051] In step 3, the old SGSN determines from the 
Relocation Required message if the SRNS relocation is 
intra-SGSN or inter-SGSN SRNS relocation. An in- 
tra-SGSN procedure is performed whenthe old and new 
SGSNs are the same, and an inter-SGSN procedure is 
performed when the two are different. A Forward Relo- 
cation Request message is applicable only in the case 
of inter-SGSN SRNS relocation. 
[0052] In step 4, the new SGSN sends a Relocation 
Request message to the target RNC so that the neces- 
sary resources are allocated between the target RNC 
and the new SGSN. After all necessary resources are 
successfully allocated, the target RNC sends the Relo- 
cation Request Acknowledge message to the new SG- 
SN. 

[0053] In step 5, when a resource for the transmission 
of user data between the target RNC and the new SGSN 
have been allocated and the new SGSN is ready for 
SRNS relocation, the Forward Relocation Response 
message is sent from the new SGSN to old SGSN. 
[0054] In step 6, the old SGSN continues SRNS relo- 
cation by sending a Relocation Command message to 
the source RNC. The source RNC is ready for forward 
downlink user data directly to the target RNC. 
[0055] In step 7, when the source RNC is ready for 
data-forwarding, it triggers execution of SRNS reloca- 
tion by sending a Relocation Commit message to the 
target RNC. 

[0056] In step B, the source RNC begins to forward 
data for the radio access bearers. The data forwarding 
may be carried out through the lu interface, which 
means that data is not directly exchanged between the 
source RNC and the target RNC but through the core 
network. 

[0057] In step 9, the target RNC sends a Relocation 
Detect message to the new SGSN. When the Reloca- 
tion Detect message is sent, the target RNC starts 
SRNC operation. 

[0058] In step 1 0, the target RNC sends a UTRAN mo- 
bility information (Case i) message or a Cell/URA 
(UTRAN registration area) update (Case II) message to 
the terminal. Both messages contain terminal informa- 
tion elements and core network information elements. 
The terminal information elements include new U-RNTI 
used for the identification of the terminal in the target 
RNC. The core network information elements include lo- 
cation area identification and routing area identification 
information. 
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[0059] Upon receipt of the UTRAN Mobility Informa- 
tion message the terminal can start sending uplink (UL) 
user data to the target RNC. When the terminal has 
reconfigured itself, it sends the UTRAN Mobility Infor- 
mation Confirm message to the target RNC. This indi- 
cates that the terminal is also ready to receive downlink 
(DL) data from the target RNC. 
[0060] In step 11 , upon receipt of the Relocation De- 
tect message the core network switches the user plane 
from source RNC to target RNC. In the case of an in- 
ter-SGSN SRNS relocation, the new SGSN sends Up- 
date PDP Context Request messages to the GGSNs 
concerned. The GGSNs update their PDP context fields 
and return an Update PDP Context Response. 
[0061] In step 12, when the target RNC receives the 
UTRAN Mobility Information Confirm message, <i.e., the 
new U-RNTI is successfully exchanged with the terminal 
by the radio protocols), the target RNC sends the Relo- 
cation Complete message to the new SGSN. The pur- 
pose of the Relocation Complete message is to indicate 
by the target RNC completion of the relocation of the 
SRNS to the core network. In the case of an inter-SGSN 
SRNS relocation, the new SGSN signals the old SGSN 
of the completion of the SRNS relocation procedure by 
sending a Forward Relocation Complete message. 
[0062] In step 1 3, upon receiving the Relocation Com- 
plete message or the Forward Relocation Complete 
message, the old SGSN sends an lu Release Command 
message to the source RNC so that the lu connection 
between the source RNC and the old SGSN is released. 
[0063] Figure 7 shows the steps of the SRNS reloca- 
tion procedure including the exchange of RRC messag- 
es between the UTRAN and the terminal. In this figure, 
RRC messages are transmitted at steps 1 , 7, and 8, and 
the UTRAN can either be the source RNC or target RNC 
depending on the case. Also, UE refers to user equip- 
ment and therefore may include a user terminal. The 
RRC messages transmitted in this procedure are de- 
scribed as follows. 

(1) Cell Update message and Cell Update Confirm 
message : When the terminal moves to a new cell, 
a Cell Update message is sent from the terminal to 
the UTRAN. If the UTRAN decides to perform 
SRNS relocation, the target RNC sends the Cell Up- 
date Confirm message to the terminal as a re- 
sponse to the Cell Update message. The Cell Up- 
date Confirm message contains the new U-RNTI, 
which indicates to the terminal the SRNS relocation 
procedure being performed. The Cell Update mes- 
sage is transmitted through SRB0 using TM RLC, 
and the Cell Update Confirm message is through 
either SRB0 or SRB1 using UM RLC. 

(2) U RA Update massage and URA Update Confirm 
message : A URA (UTRAN registration area) is an 
area comprised of one or several cells, and is inter- 
nally known to the UTRAN. The URAs may partially 
overlap in order to prevent a ping-pong effect of the 
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terminal. Therefore, one cell -can belong to one or 
more URAs. The terminal knows the current URA 
identity from the URA list broadcast in each cell and 
performs the URA update procedure whenever the 
URA is changed. 

The URA update procedure is initiated when 
the terminal sends the URA Update message to the 
UTRAN. The UTRAN transmits the URA Update 
Confirm message in response to the URA Update 
message to the terminal, in order to inform the ter- 
minal of the new URA identity. The URA Update 
Confirm message includes a new U-RNTI which is 
the same as in the Cell Update Confirm message. 
The URA Update message is transmitted through 
SRBO using TM RLC, and the URA Update Confirm 
message is transmitted through SRBO or SRB1 us- 
ing UM RLC. 

(3) UTRAN Mobility Information massage and 
UTRAN Mobility Information Confirm message : The 
UTRAN Mobility Information message is used when 
the UTRAN assigns a new U-RNTI to the terminal 
or when mobility information is transmitted. The ter- 
minal transmits UTRAN Mobility information Con- 
firm message in response. After successfully trans- 
mitting the UTRAN Mobility Information Confirm 
message, the target RNC and the terminal estab- 
lish/re-establish the PDCP and RLC entities using 
CPDCP-CONFIG-Req and CRLC-CONFIG-Req 
commands, respectively. The UTRAN Mobility In- 
formation message is transmittedthrough SRB1 us- 
ing UM RLC or SRB2 using AM RLC. The UTRAN 
mobility Information Confirm message is transmit- 
ted through SRB2 using AM RLC. 

Ciphering 

[0064] The SRNS relocation procedure has been de- 
scribed in terms of the steps taken in both the UMTS 
system and the UTRAN. From this description, It is clear 
that the SRNS relocation procedure is primarily based 
on the exchange of messages between the terminal and 
RNC, and between the RNC and the core network. 
Among these messages, RRC messages exchanged 
between the terminal and the RNC are usually ciphered 
for the sake of security. 

[0065] In some cases, the ciphered RRC messages 
cannot be deciphered in the receiver because the ci- 
phering parameters are different between the terminal 
and the UTRAN. In order to gain a better understanding 
of this problem, the ciphering method in general must 
first to be considered. 

[0066] Ciphering is a method which prevents unau- 
thori2ed access of data, for example, as a result of 
eavesdropping. Because unique ciphering parameters 
exist between the terminal and the RNC, a user who 
does not know the ciphering parameters cannot deci- 
pher the data. 

[0067] The ciphering method adopted by the 3GPP is 



performed in the RLC layer or the MAC layer according 
to the RLC mode of operation. That is, when the RLC 
mode is AM or UM, ciphering is performed in the RLC 
layer. When the RLC mode is TM, ciphering is per- 
s formed in the MAC layer. Preferably, in this system ci- 
phering is applied only for the DCCH and DTCH chan- 
nels. 

[0068] During this ciphering met hod, a MASK used for 
ciphering is generated based on various input parame- 

10 ters. The MASK is then added to RLC PDUs or MAC 
SDUs to generate the ciphered data. In the user termi- 
nal, the same MASK is used to decipher the data. 
[0069] Figure 8 shows steps included in the ciphering 
process. Here, PLAINTEXT BLOCK is the data before 

»5 ciphering and KEYSTREAM BLOCK is a ciphering 
MASK. The PLAINTEXT BLOCK is ciphered to Cl- 
PHERTEXT BLOCK through a bit operation with the 
KEYSTREAM BLOCK. Then, the ciphered CIPHER- 
TEXT BLOCK is transmitted to a radio interface. After 

20 receiving the CIPHERTEXT BLOCK, the receiver deci- 
phers it by applying the KEYSTREAM BLOCK that is 
the same MASK as in the transmitter. That is, if the ci- 
phered data is extracted during transmission, the data 
cannot be deciphered unless the KEYSTREAM BLOCK 

2S is known. 

[0070] The core technology of ciphering lies in the 
generation of the KEYSTREAM BLOCK, i.e. the cipher- 
ing MASK. To achieve effective results, the MASK 
should have the following characteristics. First, genera- 

30 tion of the MASK by reverse tracing should be impossi- 
ble. Second, each radio bearer RB should have its own 
MASK. Third, the MASK should continuously change 
over time. 

[0071] Among the various ciphering algorithms that 
35 exist, a method referred to as F8 has been adopted by 
3GPP communications systems. The FB algorithm gen- 
erates the KEYSTREAM BLOCK using input parame- 
ters including: 

40 CK (Ciphering key, 128 bits): There is one CKcs for 
a circuit-switching based service domain and one 
CK PS for a packet-switching based service domain. 
BEARER (Radio Bearer Identifier, 5bits): One value 
exists for each RB. 
*s DIRECTION (Direction Identifier, 1bit): Indicates 
the direction of the RB. It is set to 0 for uplink and 
1 for downlink. 

LENGTH (16bits): Indicates the length of the KEY- 
STREAM BLOCK, i.e. the generated MASK. 
50 COUNT-C (32bits): A ciphering sequence number. 
For RBs using AM or UM RLC, one COUNT-C is 
used for each RB. For RBs using TM RLC, one 
COUNT-C value is used for all the RBs. Those 
skilled in the art can appreciate that the bit and other 
55 values provided above are preferred values and 
may be changed if desired. 

[0072] Among the ciphering input parameters, 
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COUNT-C is the only time-varying parameter. That is, 
different COUNT-C values are used for each PDU. Oth- 
er ciphering input parameters are fixed parameters and 
therefore the same values may be used for these pa- 
rameters for all PDUs in a data stream. The COUNT-C 
parameter is divided into two parts: a forward part and 
a rear part. The forward part includes a long sequence 
number and the rear part includes a short sequence 
number. 

[00731 Figure 9 shows detailed structures of the 
COUNT-C parameter for the various modes of operation 
of the RLC layer. The respective structures are as fol- 
lows: 

TM RLC case 

* t. 

long sequence number: MAC-d Hyper Frame 
Number (HFN) of 24 bits 
short sequence number: Connection Frame 
Number (CFN) of 8 bits 

UM RLC case 

long sequence number: RLC Hyper Frame 
Number (HFN) of 25 bits 
short sequence number: RLC UM Sequence 
Number (SN) of 7 bits 

AM RLC case 

long sequence number: RLC Hyper Frame 
Number (HFN) of 20 bits 
short sequence number: RLC AM Sequence 
Number <SN) of 12 bits 

[0074] The CFN is a counter for synchroni2ing the 
transport channels of the MAC layer between the termi- 
nal and the UTRAN. The CFN may have a value be- 
tween 0 and 255 and it increases by one for each radio 
frame (10ms). 

[0075] The RLC SN is a sequence number used for 
identifying each RLC PDU. For UM RLC, the RLC SN 
has a value between 0 and 127 (7 bits). For AM RLC, 
the RLC SN has a value between 0 and 4095 (12 bits). 
The RLC SN increases by 1 for each RLC PDU. 
[0076] Since a short sequence number is too short to 
be used alone for COUNT-C. a long sequence number 
known as HFN is added in front of the short sequence 
number. More specifically, the HFN corresponds to the 
MSBs (Most Significant Bits) and short sequence 
number corresponds to the LSBs (Least Significant Bits) 
of the COUNT-C. Therefore, HFN is increased by 1 
when the short sequence number wraps around to 0. 
The adjustment of this HFN is one of the factors which 
causes ciphering problems to occur in related art sys- 
tems, details of which will now be discussed. 



Drawbacks of Related- Art SRNS Relocation 
Procedures 

{0077] Ciphering problems are usually caused when 
5 the HFNs become out of synchronization between the 
RLC entities of the terminal and the RNS (or RNC) in 
the UTRAN. This synchronization problem is mainly at- 
tributable to the COUNT-C parameter. More specifically, 
as previously discussed, all ciphering parameters ex- 
10 cept COUNT-C are fixed parameters and therefore may 
remain synchronized throughout the connection. The 
short sequence number {i.e. the LSBs of the COUNT-C) 
is also synchronized because, for TM RLC, the CFN is 
known to both the terminal and the UTRAN and, for UM 
is and AM RLC, the RLC SN is included in the PDU header 
and transmitted through the radio interface. For TM 
RLC, the long sequence number corresponding to HFN 
is also synchronized because the CFN is calculated 
from the SFN (System 'Frame Number) which is contin- 
ue uously broadcast in a cell. For UM and AM RLC, how- 
ever, the HFN is sometimes out-of-synchronization due 
to lost or re-transmitted RLC PDUs. This condition is ex- 
plained in greater detail below. 
[0078] Under normal conditions, the HFN is never ex- 
25 changed and is locally managed by the terminal and the 
UTRAN. The locally managed HFNs may become out- 
of-synchronization for UM and AM RLC modes when 
RLC PDUs are lost or re-transmitted, as previously men- 
tioned. If the HFN values managed by the terminal and 
so the UTRAN become different, then the MASKs used in 
the terminal and the UTRAN also become different. As 
a result, the ciphered data cannot be deciphered in the 
receiver. Thus, once the HFNs become out-of-synchro- 
nization, data transmission cannot be successfully per- 
35 formed until the HFNs are synchronized. 

[0079] The problems in the related-art SRNS reloca- 
tion procedure are caused when this ciphering problem 
(i.e., unsynchronized HFNs) arises in UM and AM RLC 
operation. In Figure 7, these problems affect steps 7 and 
40 8. The manner in which the steps are adversely affected 
will now be described in detail. (Note that step 1 has no 
ciphering problem since the RRC message is transmit- 
ted using TM RLC). 



[0080] In Case I (UE not involved) and Case II (UE 
involved), RRC messages are transmitted to the termi- 
nal using an appropriate serving radio bearer SRB. The 
50 RLC layer in the target RNC is newly generated and the 
status variables and timers are initialized. As a result of 
this initialization, the sequence number of the RLC PDU 
transmitted from the RLC layer in the target RNC to the 
terminal is initialized to 0 (zero). The terminal RLC layer, 
55 however, may be expecting the next PDU it receives to 
have a different sequence number. The possible prob- 
lems in transmitting RRC messages resulting from this 
discrepancy will be described for each of these cases. 
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(1) UTRAN Mobility Information Message is Trans- 
mitted Through SRB1: In this case, the relocation 
procedure is performed during a UM RLC mode of 
operation. During this procedure, the UTRAN HFN 

is transferred from the source RNC to the target 5 
RNC and the target RNC transmits a protocol data 
unit (PDU) including the UTRAN HFN to the termi- 
nal. As previously explained, however, before the 
PDU is transmitted its sequence number is initial- 
ized to some number, e.g., zero. In most cases, this io 
initialized value does not correspond to the se- 
quence number of the next PDU the terminal ex- 
pects to receive. As a result, when the terminal re- 
ceives the PDU with Its initialized sequence 
number, It concludes that one or more PDUs have w 
not been successfully received, e.g., there are 
some missing PDUs. The terminal will therefore op- 
erate based on the assumption that an RLC se- 
quence-number wrap around condition~has~oc- " 
curred. When this condition is detected, the trans- 20 
mitter RLC will alter its ciphering information by In- 
crementing its HFN parameter by one. This 
presents the following problem. 

When the relocation procedure caused the 
serving RNS (SRNS) to change from the source & 
RNC to the target RNC, the value of the HFN pa- 
rameter was not changed. As a result, the target 
RNC will transmit PDUs with the original UTRAN 
HFN value. The terminal, however, will attempt to 
decipher these PDUs with the newly incremented so 
HFN value. Because the terminal and UTRAN are 
operating based on different HFN values, the termi- 
nal and UTRAN (target RNC) are considered to be 
out of synchronization and the transmitter will not 
be able to decipher any PDUs from the UTRAN. 35 

(2) UTRAN Mobility Information Message is Trans- 
mitted Through SRB2 : In this case, the relocation 
procedure is performed during AM RLC mode of op- 
eration, and the terminal RLC only accepts PDUs 
having sequence numbers that fall within a valid <o 
range, which is maintained for purposes of efficient 
management of data re-transmissions. This valid 
range is defined by the size and position of a receiv- 
ing window maintained by the terminal receiver dur- 
ing AM operation. When the terminal receives RLC «« 
PDUs which lie outside of the receiving window, the 
terminal just discards these PDUs. 

During the relocation procedure, the next PDU 
transmitted to the terminal has a sequence number 
which has been initialized to zero. If this sequence 
number lies outside of the receiving window of the 
transmitter, it will be immediately discarded. How- 
ever, even if the sequence number lies within the 
range of the receiving window, the PDU will not be 
able to be deciphered by the transmitter. This is be- 55 
cause the next sequence number the terminal ex- 
pects to receive does not correspond to the se- 
quence number of the received PDU. The terminal 



will therefore conclude that missing PDUs exist and 
that a wrap-around condition with respect to PDU 
sequence numbers has occurred. When this condi- 
tion is detected, the transmitter RLC will alter Its ci- 
phering information by incrementing Its HFN pa- 
rameter by one, thereby causing the HFN of the ter- 
minal and the HFN of the UTRAN to be different. 
This discrepancy will prevent the terminal from de- 
ciphering any data from the UTRAN 
(3) Cell/URA Update Confirm Message is transmit- 
ted through SRB1 : In this case, the relocation pro- 
cedure is performed during UM RLC operation. The 
same problem occurs as in (1) above, I.e., the RRC 
messages transmitted from the target RNC in step 
7 cannot be deciphered by the terminal because of 
a discrepancy In HFN values which occurred as a 
result of the initialization of the sequence number 
of the next PDU transmitted from the UTRAN. 

[0081] In all the above cases, the terminal and 
UTRAN will not be able to communicate after SRNS re- 
location has been performed unless and until the out- 
of-synchronization problem with regard to their HFNs is 
resolved. Complications which arise in connection with 
Step 8 will now be discussed. 

Problems in Step 8. 

[0082] In Case I <UE not involved) and Case II <UE 
involved), the terminal transmits a UTRAN Mobility In- 
formation Confirm message through SRB2 when the re- 
location procedure is performed during the AM RLC 
mode of operation. The similar problems occur as indi- 
cated in (2) above for step 7. The difference is that the 
roles are reversed, i.e., the transmitter is the terminal 
RLC and the receiver is the target RNC RLC. 
[0083] In view of the foregoing considerations, it is 
clear that there is a need for an improved system and 
method for performing an SRNS relocation procedure 
in a wireless communications system, and more specif- 
ically one which efficiently resolves deciphering discrep- 
ancies that arise between transmitting and receiving en- 
tities as a result of an initialization performed during the 
relocation procedure. 

SUMMARY OF THE INVENTION 

[0084] An object of the invention is to solve at least 
the above problems and/or disadvantages and to pro- 
vide at least the advantages described hereinafter. 
[0085] Another object of the present invention is to 
provide a system and method for performing an SRNS 
relocation procedure in a wireless communications sys- 
tem in a manner which increases transmission efficien- 
cy compared with other systems which have been pro- 
posed. 

[0086] Another object of the present invention is to 
achieve the aforementioned object by efficiently resolv- 
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ing deciphering discrepancies that arise between trans- 
mitting and receiving entities when an initialization step 
is performed in the relocation procedure. 
[0087] Another object of the present invention is to re- 
solve these deciphering discrepancies by ensuring that s 
the transmitting and receiving entities operate using the 
same HFN parameter during or immediately after the 
relocation procedure is performed. By coordinating this 
information, the out-of -synchronization problem that 
other proposed systems experience is resolved. In ac- 10 
cordance with one embodiment, the transmitting entity 
may be a UTRAN RNC and the receiving entity may be 
a user terminal, otherwise known as user equipment in 
the standards developed by the 3GPP, including but not 
limited to the universal mobile telecommunications sys- w 
tern (UMTS) which is one form of IMT-2000 system. In 
another embodiment, the transmitting entity may be the 
user terminal and the receiving entity may be a UTRAN 
RNC: The present invention is also advantageous be- 
cause it may be applied to UM and AM modes of RLC 20 
operation. 

[0088] The loregoing and other objects of the inven- 
tion are achieved by providing a system and method 
which performs SRNS relocation in a mobile communi- 
cation system, and more specifically in a serving radio 2$ 
network sub-system which includes a radio network 
controller for managing a radio resource allocated to a 
terminal in the mobile communication system. In ac- 
cordance with one embodiment, the method includes re- 
serving a requiring resource in a serving radio network 30 
sub-system relocation on a network; transmitting a radio 
resource control message corresponding to the serving 
radio network sub-system relocation to the terminal in 
order that the radio network controller communicates 
the terminaL and transmitting a response radio resource 35 
control message corresponding to the serving radio net- 
work sub-system relocation to the radio network control- 
ler to which the radio resource control message is trans- 
mitted. 

[0089] The radio network controller transmits data by <o 
setting a corresponding radio link layer and adjusting a 
frame number used for ciphering so that the terminal 
successfully restores ciphered data before the radio net- 
work controller transmits the corresponding radio re- 
source control message to the terminal. The Irame «5 
number is increased by 1 more than a value used at a 
present time, and a unit data of the corresponding radio 
link layer is transmitted by ciphering. A radio resource 
control layer may transmit a command for setting a link 
control layer and the frame number to the corresponding 50 
radio link control layer. 

[0090] In addition to these steps, an original radio net- 
work controller may perform the role of a serving radio 
network controller before the serving radio network sub- 
system relocation transfers status information of a radio 5* 
link control layer used at a present time to a target radio 
network controller. This is perlormed so that the terminal 
successfully receives a serving radio resource control 
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message before the target radio network controller 
transmits a radio resource control message correspond- 
ing to the serving radio network sub-system relocation 
to the terminal. The transferred status information may 
include a parameter corresponding to the radio link con- 
trol layer operated in an unacknowledged mode. Also, 
a first sequence number of a unit data of the radio link 
control layer including the radio resource control mes- 
sage corresponding to the serving radio network sub- 
system relocation transferred from the target radio net- 
work controller to the terminal is transmitted by being 
set with a VT(US) of a parameter corresponding the ra- 
dio link control layer operated in the unacknowledged 
mode. 

[0091] In accordance with another embodiment, the 
transferred status information includes a parameter or 
data corresponding to the radio link control layer oper- 
ated in an acknowledged mode. Also, a first sequence 
number of unit data of the radio link control layer includ- 
ing the radio resource control message corresponding 
to the serving radio network sub-system relocation 
transferred from the target radio network controller to 
the terminal is transmitted by being set with a VT(US) 
of a parameter corresponding the radio link control layer 
operated in the unacknowledged mode. The radio link 
control layer of the target radio network controller may 
transmit unit data of the radio link control layer being 
transmitting which is transferred from the original radio 
network controller. 

[0092] The original radio network controller finishes 
transmission of the radio resource control message be- 
ing transmitting or being waited for being transmitted pri- 
or to transferring parameter corresponding to the radio 
link control layer operated in the acknowledged mode. 
[0093] The radio link control layer of the target radio 
network controller transmits a receiving window move- 
ment command to a radio link control layer of the termi- 
nal in order to prevent a transmission of an unit data of 
the radio link control layer having a sequence number 
below a sequence number of VT{S)-1 . The radio re- 
source control layer of the target radio network controller 
indicates the radio link control layer to start the receiving 
window movement command in order to transmit the re- 
ceiving window movement command. 
[0094] In the foregoing embodiments, the radio re- 
source control layer transfers the parameter or the data 
transferred from the original radio network controller to 
the radio link control layer. Also, a value of a field of a 
length indicator of the unit data ot a first radio link control 
layer including the radio resource control message 
transmitted from the target radio network controller to 
the terminal after the serving radio network sub-system 
relocation Indicates an information that the unit data of 
the corresponding radio link control includes the radio 
resource control message from a first portion thereof. 
[0095] In addition to these features, any one or more 
of the embodiments of the present invention may in- 
clude an initialization step for the radio link control layer, 
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where a status variable is initialized and a frame number 
is synchronized between the radio link control layer of 
the terminal and the radio link control layer of the target 
radio network controller. This will enable the terminal to 
successfully receive the radio resource control mes- 5 
sage before the target radio network controller transmits 
the radio resource control message corresponding to 
the serving radio network sub-system relocation to the 
terminal. The target radio network controller may trans- 
mit an initial unit data to the radio link control layer of 
the terminal as a command performing an initialization 
of the radio link control. 

[0096] Further, the radio resource control layer of the 
target radio network controller may transfer an initialize* 
tion start command to the radio link control layer in order 
that the radio link control layer, of the target radio con- 
troller start in an initialization process of the radio link 
control layer. 

[0097] The radio link control layers of the target radio 
network controller and the terminal are preferably set in 
order to allow the target radio network controller to suc- 
cessfully receive the corresponding radio resourcecon- 
trol message before the terminal transmits the radio re- 
source control message corresponding the serving ra- 
dio network sub-system relocation to the target radio 
network controller. Here, a frame number may be syn- 
chronized during setting of the radio link control layers 
of the target radio network controller and the terminal. 
A setting of the frame number may be transferred from 
an upper layer, and may be performed by increasing 
frame numbers used in the terminal and the target radio 
network controller by 1 (one). Alternatively, setting of the 
frame numbers used in the radio link control layer of the 
terminal and the radio link control layer of the target ra- 
dio network controller may be performed by increasing 
a larger value among an uplink frame number and a 
downlink frame number used in the radio link control lay- 
er of the terminal and the radio link control layer of the 
target radio network controller by 1 (one) based on the 
larger value. 

[0098] The radio resource control layers of the termi- 
nal and the target radio network controller transmit re- 
spective command for a setting/resetting of conespond- 
ing radio link control layers. 

[0099] A setting/resetting of a signaling radio bearer 
and a radio bearer in the terminal and the target radio 
network controller are performed after a process that the 
terminal transmits a response radio resource control 
message corresponding to the serving radio network 
sub-system relocation to the target radio network con- 
troller. Here, a frame number in the setting/resetting of 
the signaling radio bearer and the radio bearer between 
the terminal and the target radio network controller is 
set to a frame number initial value included in the re- 
sponse radio resource control message corresponding 
to the serving radio network sub-system relocation 
transmitted from the terminal to the target radio network 
controller. The frame number initial value included in the 



radio resource control message may correspond to an 
initial value stored in a ciphering module of the terminal 
defined in a Universal Mobile Telecommunications Sys- 
tem standard of asynchronous IMT2000 system. 
[0100] Additional advantages, objects, and features 
of the invention will be set forth in part in the description 
which follows and in part will become apparent to those 
having ordinary skill in the art upon examination of the 
following or may be learned from practice of the inven- 
tion. The objects and advantages of the invention may 
be realized and attained as particularly pointed out in 
the appended claims. 

BRIEF DESCRIPTION OF THE DRAWINGS 

[0101] The invention will be described in detail with 
reference to the following drawings in which like refer- 
ence numerals refer to like elements wherein: 

Figure 1 shows a network architecture of a Univer- 
sal Mobile Telecommunications System (UMTS); 
Figure 2 shows a structure of a radio interface pro- 
tocol which may be implemented within the UMTS 
system; 

Figure 3 shows a structure of a Protocol Data Unit 
(PDU) used in a Radio Link Control (RLC) layer of 
the radio interface protocol of Figure 2; 
Figure 4 is an exemplary snapshot of the state of 
an AM RLC buffer; 

Figure 5 is a diagram illustrating the concept of an 
SRNS Relocation procedure; 
Figure 6 is an SRNS Relocation signaling proce- 
dure in UMTS system; 

Figure 7 is an SRNS Relocation signaling proce- 
dure of a related-art system which includes a UMTS 
Tenestrial Radio Access Network (UTRAN); 
Figure 8 shows a ciphering process performed in 
the radio interface protocol of Figure 2; 
Figure 9 is the structure of COUNT-C parameter 
used within RLC mode; 

Figure 1 0 is a flow diagram showing steps included 
in a series of embodiments of the method of the 
present invention identified as A1 and A2 for per- 
forming an SRNS relocation procedure; 
Figure 11 is a flow diagram showing steps Included 
in a series of embodiments of the method of the 
present invention identified as B1 and B2 for per- 
forming an SRNS relocation procedure; 
Figure 1 2 is a flow diagram showing steps included 
in a series of embodiments of the method of the 
present invention identified as C1, C2, andC3 for 
performing an SRNS relocation procedure; 
Figure 13 is a flow diagram showing steps included 
in an embodiment of the method of the present in- 
vention which performs SRNS relocation for the 
case of lossless radio bearers; and 
Figure 1 4 is a flow diagram showing steps included 
in an embodiment of the method of the present in- 
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vention which performs SRNS relocation for the 
case of seamless radio bearers. 

DETAILED DESCRIPTION OF PREFERRED 
EMBODIMENTS 

[0102] The present invention is a system and method 
for performing an SRNS relocation procedure in a wire- 
less communications system. The relocation procedure 
is performed in a manner which prevents an out-of-syn- 
chronization condition from arising between transmitting 
and receiving entities. In one embodiment, the invention 
synchronizes ciphering information in the transmitting 
and receiving entities. By taking these steps, the present 
invention improves the reliability and efficiency of com- 
munications in the system. While the invention is suita- 
ble for use in a UMTS system, those skilled in the art 
can appreciate that the method may be performed in 
communications systems which adhere to other stand- 
ards and/or protocols. 

[0103] The method of the present invention controls 
the manner in which information is transmitted between 
a receiver and transmitter, and is especially well suited 
for use in the non-limiting application of where the trans- 
mitter is a UTRAN and the receiver is a user terminal 
(or user equipment as It is called by the 3GPP initiative). 
When applied in this manner, the steps of the method 
may differ depending upon the type of SRNS relocation 
to be performed and the mode of operation of the RLC 
layers of the UTRAN and user terminal. 
[0104] The SRNS relocation procedure may be clas- 
sified into two cases. In Case l f SRNS relocation is ini- 
tiated by the core or another network and the terminal 
is not informed that relocation is performed until the re- 
location procedure is terminated. Case I may therefore 
be characterized as corresponding to the situation 
where the terminal is not involved in making the decision 
to perform relocation. In Case II, SRNS relocation Is in- 
itiated by the user terminal. The terminal is therefore 
aware that relocation is being performed at the very start 
of the procedure. Case II may therefore be character- 
ized as corresponding to the situation where the termi- 
nal is involved in making the decision to perform SRNS 
relocation. 

[0105] The various embodiments of the present In- 
vention method may be initially understood by distin- 
guishing them from the related-art method of Figure 7. 
While the present invention may share some of the 
steps in the related-art method, the following discussion 
makes clear that the present invention advantageously 
overcomes the synchronization and other problems that 
arise in this system. A description of the re!ated-art sys- 
tem will therefore be initially be provided. 
[0106] Referring to Figure 7, an initial step of the 
method differs depending upon whether the SRNS re- 
location procedure is requested by the network (Case I) 
or user terminal (Case II). In Case I, the method of the 
present invention begins when the network decides to 



perform SRNS relocation, i.e., when the UTRAN de- 
cides to switch from one RNS (or a source RNC) to an- 
other RNS (or a target RNC) for purposes of communi- 
cation with the user terminal. (Step 2). The network may 

b decide to perform an SRNS relocation based on any one 
of a variety of factors. For example, relocation may be 
desirable to reduce the amount of traffic being handled 
by the source RNC, to locate a shorter or more efficient 
communications path for purposes of handling e call 

10 with the user terminal, or other reasons which may be 
understood by those skilled in the art. 
[01 07] In Case II, the method of the present invention 
begins when the user terminal transmits an RRC mes- 
sage in the form of a Cell/URA Update message to the 

is source RNC. (Step 1). This message includes a request 
for changing the SRNS of the UTRAN. Such a message 
may be transmitted, for example, when the user terminal 
moves to a new cell within the wireless system, e.g., 
when a handoff operation is imminent or required. At this 

20 time, the network may decide whether to favorably re- 
spond by satisfying the request or may immediately re- 
spond. 

[0108] The second through fifth steps are commonly 
performed for Cases I and II. In the second step, relo- 
25 cation preparation is performed. (Step 3). This involves 
forwarding relevant parameters for communicating with 
the user terminal from the source RNC to the target RNC 
through an RRC information container. This container 
includes, for example, ciphering information (e.g., 

3D downlink HFN and uplink HFN parameters) for signaling 
radio bearers, as well as radio resources including new 
RABs for purposes of changing the serving RNS from 
the source RNC to the target RNC. The type of radio 
bearers reserved in this step depends on whether AM 

35 or UM RLC mode is being supported in the UTRAN. If 
AM mode is supported, one or more lossless radio bear- 
ers are reserved so that lossless SRNS relocation may 
be performed. If UM mode is supported, one or more 
seamless radio bearers are reserved so that seamless 

40 SRNS relocation may be performed. 

[0109] The third step includes receiving an RANAP 
Relocation Command from the core network, and more 
specifically from an existing SGSN in the core network. 
(Step 4). The existing SGSN may be referred to as the 

*5 "old SGSN," and If relocation results in requiring a 
change of SGSNs (which may not always be the case) 
a "new SGSN" will be assigned after relocation. The Re- 
location Command informs the source RNC of the RABs 
to be released and the RABs that are subject to data 

50 forwarding in connection with the relocation procedure. 
Lossless SRNC (performed for AM RLC operation) may 
be configured for RABs subject to data forwarding. The 
PDCP layer supports PDCP sequence numbering when 
lossless SRNS relocation is supported. 

55 [0110] The fourth step includes transmitting a Relo- 
cation Commit message from the source RNC to the tar- 
get RNC. (Step 5). In this step, for the affected radio 
bearers, the source RLC is stopped and the PDCP 
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transmission sequence numbers are retrieved by the 
RRC. The PDCP of the source RNC transfers the se- 
quence numbers and other information for communicat- 
ing with the user terminal to the target RNC. 
[0111] The fifth step includes transmitting an RANAP 
Relocation Detect message from the target RNC to the 
source RNC. (Step 6). When this message is received, 
the target RNC becomes the serving RNC. A corre- 
sponding change from the old SGSN to the new SGSN 
may be performed at this time. After these steps, the 
relocation has occurred. 

[0112] The sixth step includes transmitting an RRC 
message from the target RNC to the user terminal, and 
more specifically to the RRC layer of the user terminal. 
In Case I, the RRC message is in the form of a UTRAN 
Mobility Information message, in Case II, the RRC mes- 
sage is in the form of a Cell/URA Update Confirm mes- 
sage. In each of these messages, a new U-RNTI is in- 
cluded to inform the user terminal that an SRNS reloca- 
tion procedure was performed. 
[0113] A seventh step includes calculating a START 
value in the user terminal in response to downlink coun- 
ter synchronization information. The START value is 
then transmitted from the user terminal to the RRC layer 
of the target RNC in an RRC message called a UTRAN 
Mobility Information Confirm message. (Step 7). 
[0114] An eighth step includes establishing RLC en- 
tities in the target RNC based on the START value in- 
cluded in the UTRAN Mobility Information Confirm mes- 
sage. In the meantime, the user terminal may also re- 
establish its RLC entities with the transmitted START 
value. (Step 8). 

[0115] The foregoing description may serve as a 
framework for the approach taken by the method of the 
present invention for overcoming the out-of-synchroni- 
zation problem that adversely affects the performance 
of the related- art method of Figure 7. This problem oc- 
curs in the sixth step discussed above. 
[0116] In this step, the target RNC transmits an RRC 
message either on SRB1 or SRB2 depending upon the 
case and the mode of operation of the RLC entities. 
More specifically, either a UTRAN Mobility Information 
message is sent on an AM/DCCH (SRB2) or UM/DCCH 
(SRB1 ), or a Cell URA Update Confirm message is sent 
on UM/DCCH (SRB1). Although the Cell/URA Update 
Confirm message can use UM/CCCH (SRB0), SRNS 
relocation policy (if SRNS is relocated before the Cell/ 
URA Update confirmation is sent, a DCCH should be 
used to allow ciphering of the messege contents) may 
require that this message should not use SRB0 in case 
of SRNS relocation. 

[0117] When the steps shown in Figure 7 are per- 
formed, out-of-synchronization problems arise between 
the user terminal and UTRAN which prevent communi- 
cations from being performed. Some of these problems 
occurs as follows. 

[0118] Problem 1 : CL RRC Message is Sent on SRB1 
(UM/DCCH) . Before SRNS relocation, the source RNC 



may be communicating PDUs with the user terminal 
based on synchronized deciphering information, for ex- 
ample, the source RNC may transmit PDUs based on a 
downlink HFN parameter = X and a transmission se- 

s quence number corresponding to a state variable VT 
(US) = 50 for UM mode of operation. Similarly, the user 
terminal may transmit PDUs based on an uplink HFN = 
X and a VR(US) = 50. Because the deciphering infor- 
mation and transmission sequence numbers are syn- 

10 chronized, the user terminal and source RNC can com- 
municate without problems. However, when SRNS re- 
location occurs, since the HFN value is transferred from 
the source to the target RNC without any additional In- 
formation (e.g., without transmission sequence number 

is information in the form of one or more of state variables 
VT(US) or VR(US)), the target RNC establishes a UM 
RLC entity with the same deciphering information used 
by the source RNC (i.e., DL HFN = X) but with state var- 
iable VT(US) set to a newly initialized value, e.g., zero. 

so [0119] Accordingly, when the target RNC sends an 
RRC message to the user terminal, the user terminal 
will in most cases recognize the transmission sequence 
number in the RRC messege as corresponding to an 
out- of- sequence number, because it does not include 

25 the sequence number that follows the last PDU trans- 
mitted by the source RNC. When this occurs (e.g., when 
the user terminal detects that the received RRC mes- 
sage has a serial number SN = 0), it will conclude that 
a new PDU has been received and more specifically that 

so PDUs having serial numbers of between 50 and 1 27 are 
missing. As a result, the user terminal will increase Its 
HFN to a value of X + 1 for purposes of deciphering fu- 
ture PDUs. However, the target RNC will continue to 
transmit PDUs based on HFN = X. Because there is a 

35 discrepancy in the deciphering information used by the 
user terminal and target RNC, the user terminal will not 
be able to decipher and thus successfully receive the 
PDUs transmitted from the target RNC. This means that 
the user terminal cannot receive the RRC message. 

40 

Problem 2: DL RRC Message is Sent on SRB2 (AM/ 
DCCH) . 

[0120] Before SRNS relocation, assume that DL HFN 
45 = x and VT(S) = 3000 in the source RNC and DL HFN 
= X and VR(R) = 3000 in the user terminal. Because the 
deciphering information and transmission sequence 
numbers are synchronized, the user terminal and 
source RNC can successfully communicate. However, 
50 when SRNS relocation occurs, since the HFN value is 
transferred fromthe source RNC to the target RNC with- 
out VT(S) indicative of transmission sequence number, 
the target RNC will establish an AM RLC entity with DL 
HFN = X but with VT(S) set to an initial value, e.g., VT 
55 <S) = 0. 

[01 21 ] When the RRC message is sent from the target 
RNC to the user terminal, the user terminal will discard 
the message If its transmission sequence number 
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(which is zero in this case) lies outside of the range of 
the receiving window. However, even if the sequence 
number of the RRC message lies within the receiving 
window, the user terminal will consider it to be a new 
PDU, i.e., that PDUs having sequence numbers from 
3000-4095 are missing. When this occurs, the user ter- 
minal sets its HFN = X + 1 . As a result, the deciphering 
information in the user terminal and target RNC are dif- 
ferent and therefore the user terminal will not be able to 
receive the ARC message transmitted from the target 
RNC. 

[0122] In both problems discussed above (5RB1 or 
SRB2), the user terminal in most cases cannot receive 
the RRC message transmitted from the target RNC. As 
a result, SRNS relocation fails . Of course, it is noted that 
there is a slim possibility that the user terminal will be 
able to receive the initial RRC message from the target 
RNC, but this can only happen when VT(US) = VR(US) 
=■ 0 or VT(S) = VR(R) = 0. However, even if the initial 
RRC message from the target RNC is successfully re- 
ceived and deciphered by the user terminal, the target 
RNC will not be able to receive the UTAN Mobility Infor- 
mation Confirm RRC message transmitted from the us- 
er terminal. This message is sent on AM/DCCH (SRB2), 
and it cannot be received by the target RNC because 
VT(S) = 3000 in the user terminal but VR(R) = 0 in the 
target RNC. 

[0123] The system and method of the present inven- 
tion overcomes these and other problems that arise in 
the related-art system as a result of synchronization and 
transmission sequence number mis-matches. As the 
following embodiments will reflect, the target RNC and 
user terminal will be controlled to synchronize all infor- 
mation required in order for a successful relocation pro- 
cedure to be performed. The specific embodiments will 
now be discussed. 

[0124] The method of the present invention may be 
performed differently depending upon whether Case I 
or Case II applies. When SRNS relocation is requested 
by the network (Case I), the sixth step includes synchro- 
nizing ciphering information in the target RNC to cipher- 
ing information that is expected to be used in the user 
terminal. This synchronization may be performed in 
view of the following realization. 
[0125] During the relocation procedure, RLC PDUs 
transmitted from the target RNC to the user terminal will 
have initialized values. For example, the first PDU trans- 
mined will be given an initial transmission sequence 
number such as zero. On the user terminal side, the 
RLC layer receives PDUs and orders them based on 
transmission sequence number. Since the user terminal 
was communicating with the source RNC prior to relo- 
cation, the next PDU the RLC of the user terminal will 
expect to receive is one whose transmission sequence 
number consecutively follows the transmission se- 
quence number of the last-received PDU. The first PDU 
transmitted from the target RNC in the UTRAN, howev- 
er, will have an initialized sequence number and thus in 



all probability will not correspond to the expected 
number. 

[0126] When this occurs once or a predetermined 
number of times, the user terminal RLC will conclude 

5 that a wrap-around condition has occurred. When such 
a condition is detected, the RLC of the user terminal will 
adjust its deciphering information by changing its HFN 
parameter to a new value. This change may involve in- 
crementing the HFN parameter by 1 . 

J0 [0127] In the related-art method of Figure 7, the target 
RNC did not compensate for this change in deciphering 
information in the user terminal. Instead, PDUs were ci- 
phered using ciphering information (i.e., the HFN pa- 
rameter) included in the RRC information container sent 

*5 from the source RNC to the target RNC. As a result, 
PDUs transmitted from the target RNC could not be de- 
ciphered by the user terminal and a stall in communica- 
tions occurred. 

[01 28] The present invention overcomes this problem 
20 by taking one of several approaches. On approach in- 
volves adjusting ciphering information in the target RNC 
received from the source RNC. This adjustment ensures 
that the target RNC ciphers PDUs with the same HFN 
parameter the user terminal will use during deciphering. 
25 Since UTRAN management software is programmed to 
know how the user terminal will adjust its HFN parame- 
ter when a PDU having an out-of-sequence transmis- 
sion sequence number is received, the target RNC may 
cipher the PDUs to be sent to the user terminal using 
30 the same adjusted HFN parameter. The nature of the 
adjustment performed by the present invention depends 
on whether Case I or II is being observed and whether 
the RLCs of the user terminal and target RNCs are op- 
erating in AM or UM mode. The following situations ap- 

35 ply. 

A. Downlink RRC Message Sent on SRB1 (UM/DCCH) . 

[0129] In this case, the RLCs of the target RNC and 
40 user terminal are operating in UM mode. The target 
RNC sends an RRC message on a serving radio bearer 
SRB1 (which corresponds to a UM DCCH channel) to 
the user terminal. The following situations apply. 

45 A.1 . Target RNC Establishes SRB1 and Increments PL 
HFN . 

[0130] Referring to Figure 10, the target RNC re- 
ceives an RRC information container from the source 

50 RNC. The container includes ciphering information 
which preferably includes an HFN parameter which the 
source RNC was using to communicate with the user 
terminal. When the RRC information container is re- 
ceived, the target RNC increments the HFN parameter 

55 and establishes a new SRB1 . Because the target RNC 
hes foreknowledge of the way in which the user terminal 
changes its HFN parameter when a wrap-around con- 
dition occurs or when an out-of-sequence PDU is re- 
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ceived, the target RNC increments Its HFN parameter 
in an identical manner. As a result, the PDUs generated 
by the target RNC will be ciphered in a way which is 
decipherable by the user terminal. 
[0131J Once the PDUs have been generated, they are s 
transmitted from a UM RLC of the target RNC to the user 
terminal. The first PDU transmitted includes an initial 
transmission sequence number, e.g., SN = 0. When the 
user terminal receives the PDUs, the user terminal de- 
tects that the first PDU has an out-of-sequence trans- 
mission sequence number. The user terminal may per- 
form this detection function by extracting state variable 
VR(US) from the first PDU. Since this state variable pro- 
vides an indication of the. transmission sequence 
number that corresponds to this PDU, a wrap-around or 
out-of-sequence condition may be detected, for exam- 
ple, in the case where VR(US) has values from 0 to 127, 
the user terminal may determine that PDUs having the 
value of the VR(US) in the received PDU to VR number 
127 are missing. 

[0132] When this condition is detected, the user ter- 
minal will adjust its HFN parameter, for example, by in- 
crementing this parameter by 1 . Since the PDUs trans- 
mitted from the target RNC were generated and trans- 
mitted in accordance with this same HFN parameter, the 
PDUs may be deciphered and communications may 
take place in spite of the relocation procedure. By syn- 
chronizing the ciphering information in the user terminal 
and target RNC, the present invention advantageously 
overcomes the out-of-synchronization problem that oc- 
curs in the related-art system ol Figure 7. 
[0133] An optional but desirable step involves includ- 
ing a data start indicator (which may be referred to as 
Special L1) in one or more PDUs transmitted from the 
target RNC to the user terminal. In accordance with the 
present invention, the data start indicator may be incor- 
porated into the PDUs transmitted by the target RNC 
over a UM DCCH channel. The inclusion of this indicator 
is advantageous. For example, if the user terminal re- 
ceives a PDU from the target RNC without the data start 
indicator, the user terminal may consider the PDU to be 
part of a previous SDU and may just discard it. When 
received by the user terminal, the data start indicator will 
be interpreted to indicate that the PDU to which it is at- 
tached is not part of a previous SDU. Including this in- 
dicator will therefore ensure that PDUs received from 
the target RNC will not be discarded. In order to maxi- 
mize transmission efficiency, the first PDU transmitted 
from the target RNC (i.e., the PDU having a transmis- 
sion sequence number SN = 0) preferably includes the 
Special L1 indicator. 

A. 2. Source RNC Transfers VT(US) to Target RNC . 

[0134] This approach differs from the approach in A. 
1. in that instead of incrementing its HFN parameter, the 
first PDU transmitted from the target RNC to the user 
terminal contains the next transmission sequence 



number which the user terminal expects to receive. 
Thus, the HFN parameter used by the target RNC and 
user terminal remains synchronized and therefore data 
communications may be performed. A more detailed de- 
scription of this approach will now be provided. 
[0135] In an initial step, the source RNC delivers an 
RRC information container 50 that includes state varia- 
ble VT(US) of serving radio bearer SRB1 to the target 
RNC. State variable VT(US) is indicative of a transmis- 
sion sequence number related to the transmission se- 
quence number of the last or one of the last PDUs trans- 
mitted from the source RNC to the user terminal. The 
target RNC uses state variable VT(US) as a basis for 
transmitting its first PDU 60 to the user terminal. For ex- 
ample, if VT(US) corresponds to the last sequence 
number transmitted, the target RNC may increment the 
transmission sequence number corresponding to VT 
(US) by one and then transmit the first PDU containing 
this value. When the user terminal receives this PDU, It 
will detect that this PDU is has the next-in-sequence 
number that it expected and thus no wrap-around or 
missing PDU condition will be detected. As a result, the 
user terminal will not increment its HFN value as in the 
previous case; and because the PDU was ciphered 
based on the same HFN value, the user terminal will be 
able to decipher it. 

[0136] As an alternative to this approach, the VT(US) 
variable delivered from the source RNC to the target 
RNC may be the next-in-sequence number which the 
user equipment expects to receive. In this case, the tar- 
get RNC will transmit the first PDU with the number cor- 
responding to VT(US). 

[0137] This approach may include a number of addi- 
tional steps. First, a new IE (Information element) may 
be used in light of the addition of VT<US) of SRB1 into 
the RRC information container. 
[0138] Second, the RLC establishment step may be 
modified. For example, when the RLC entity is estab- 
lished, all the state variables may be set to initial values 
(e.g., 0). As a result, ft may not be possible to establish 
the UM RLC entity with VT(US) other than 0. In order to 
compensate for setting the state variables to initial val- 
ues, an establish and modify procedure should be per- 
formed. That is, at first, RLC entity is established with 
all the state variables to be 0, at second, the state var- 
iables are modified to be desired values. 
[0139] Third, a data start indicator {e.g., Start LI) 
should be included in the first UM PDU transmitted from 
the target RNC to the user terminal. If the first PDU is 
transmitted without this indicator and if, for example, the 
PDU with sequence number SN = VT(US) - 1 is lost, the 
user equipment will discard the PDU. Because the user 
equipment considers that the PDU contains incomplete 
SDU a portion of which may be contained in the former 
PDU. Including the data start indicator in the first PDU 
transmitted from the target RNC will therefore guarantee 
that the RRC message will be received by the user ter- 
minal. 
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B, Downlink RRC Message Sent on SRB24AM/DCCH) . 

[0140] In this case, the RLCs of the target RNC and 
user terminal are operating in AM mode. The target RNC 
sends an RRC message on a serving radio bearer SRB2 
(which corresponds to an AM DCCH channel) to the us- 
er terminal. 

B.1 . Target RNC Establishes SRB2 and Initializes RLC 
RESET Procedure. 

[0141] Referring to Figure 11, before sending the 
RRC message, the target RNC performs an RLC RE- 
SET operation which involves resetting the transmission 
sequence number and state variables to initial values. 
Preferably at the same time, the target RNC transmits 
a Reset PDU 70 to the user terminal. According to one 
aspect of the invention, the Reset PDU is transmitted 
without being ciphered, and has no transmission-se- 
quence number. Consequently, the user terminal will be 
able to receive the Reset PDU transmitted through 
S RB2. Upon receiving the Reset PDU, the user terminal 
will reset its state variables and transmission sequence 
number to the same initial values set in the target RNC. 
[0142] Because the Reset PDU has no transmission 
sequence number, the user terminal will not detect a 
wrap-around or out-of-sequence condition when the Re- 
set PDU is received. Therefore, the HFN parameter in 
the user terminal will not be incremented. As a result, 
the HFN parameter which the target RNC received from 
the source RNC and the HFN parameter ol the user ter- 
minal will be the same. And, since the state variables 
and transmission sequence numbers of the target RNC 
and user terminal have been initialized to like values, 
the target RNC and user terminal may successfully com- 
munication with one another. When reset is completed 
in the user terminal, a reset acknowledgment message 
Reset ACK PDU 80 will be transmitted from the user 
terminal to the target RNC. 

[0143] As an alternative to this embodiment, the Re- 
set operation performed in the target RNC may cause 
the HFN parameter to be incremented. The Reset PDU 
may then be modified so that the user terminal incre- 
ments its HFN value upon receipt. This may be accom- 
plished, for example, by transmitting the Reset PDU with 
an initial or out-of-sequence transmission sequence 
number. 

[01 44] As a result of the foregoing steps, the HFN pa- 
rameters and transmission sequence numbers of the 
target RNC and user terminal will be synchronized. In 
order to achieve this synchronization, it is preferable but 
not necessary to provide a new trigger for the RLC Reset 
procedure. More specifically, under normal operating 
conditions an RLC Reset procedure is performed when 
an RLC protocol error is detected and/or when one of 
three trigger conditions specified in the 3GPP specifica- 
tion is detected. In this embodiment of the present In- 
vention, the Reset procedure may be performed when 



a fourth trigger condition is detected. Referring to the 
specification, RLC reset procedure is performed, If one 
of the following triggers is detected. 

5 1) "No_Discard after MaxDAT number of retrans- 
missions" is configured and VT(DAT) equals the 
value MaxDAT; 

2) VT(MRW) equals the value MaxMRW; 

3) A STATUS PDU including "erroneous Sequence 
10 Number* is received; 

[0145] More specifically, in accordance with an alter- 
native embodiment of the present invention, a new C- 
primitive (a control message from RRC to RLC) and a 
is new trigger in RLC protocol is used for initiating the Re- 
set procedure. 

[01 46] During the Reset procedure, at least one addi- 
tional step may be performed. In this step, all RLC SDUs 
in-the user terminal and the target RNC are flushed. 
20 Though this embodiment of the invention requires some 
time to perform and may suffer some loss of data, it pro- 
vides a clear solution to the problem of unsynchronized 
ciphering passwords realized by the related-art system. 

*5 B.2 . Source RNC Transfers VT(S) to Target RNC . 

[0147] Referring again to Figure 11, this embodiment 
of the invention is simitar to the embodiment discussed 
in A.2 above, except that a different approach is taken 
30 to account for the receiving window in the user terminal 
and the fact that RLC PDUs are re-transmitted in the AM 
operational mode. 

Accordingly, other than adjusting the sequence number 
of the RLC PDU to be transmitted to the terminal and 

35 synchronizing the HFN value, the target RNC may be 
required to consider data units previously transmitted to 
the terminal by the source RNC which were not con- 
firmed by the user terminal. The following steps may be 
taken to compensate for this prospective problem. 

40 [0148] In process step B.2.1 ., the source RNC trans- 
fers a message 90 containing information related to the 
setting of the SRB2 to the target RNC. This information 
includes the sequence number, state variable VT<S), 
and the HFN parameter used by the RLC layer of the 

45 source RNC, together with one or more RLC PDUs or 
an RRC message that is being re-transmitted. In proc- 
ess step B.2.2., the target RNC then transmits one or 
more PDUs 1 00 to be re-transmitted to the user terminal 
using the information transferred from the source RNC. 

so As a result, the target RNC will transmit the PDUs in the 
same manner and with the same information as the 
source RNC. 

[0149] As an example, consider the case where the 
source RNC transmits its HFN parameter, one or more 
55 RLC PDUs to be re-transmitted, VT<S) indicating se- 
quence number and VT(A) in step B1 of Figure 11. The 
target RNC stores the PDUs from the source RNC after 
configures the RLC layer with the received parameters 
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(Step B.2.2 in Figure 11), and sends a UTRAN Mobility 
Information Message with a new PDU starting with the 
sequence number corresponding to VT(S). Because the 
target RNC can transmit data while sustaining a re- 
transmission buffer state of the SRB2 equal to the re- 
transmission buffer state of the source RNC, the user 
terminal can recover the retransmitted data from the 
target RNC through the SRB2 channel. 
[0150] In accordance with another embodiment, the 
source RNC delivers VT(S) to the target RNC through 
an RRC information container. The target RNC then es- 
tablishes SRB2 (AM RLC) with the transferred values 
and sends an RRC message to the user terminal with 
those values. The user terminal operates in a different 
manner compared with A.2. because the AM RLC of the 
terminal receives PDUs that only lie within a valid range 
of a receiving window. 

[0151] If the transmission sequence number corre- 
sponding to variable VT(S) is equal to-VR(R),-no prob- 
lem occurs. But if VT(S) is larger than VR(R) (mainly 
due to the unconfirmed RLC SDUs in the source RLC), 
the user terminal will transmit a status PDU to the target 
RNC indicating that AMD PDUs from VR(R) to VT(S)-1 
are missing. If appropriate action is not taken, the fol- 
lowing problem may occur: Since VT(A) = VT(S), the 
target RLC finds that the received status PDU contains 
an "erroneous Sequence Number* and it will initiate a 
Reset procedure. The RLC PDUs transmitted before the 
Reset procedure is implemented will be lost (note that 
the RLC buffers may be flushed during the Reset pro- 
cedure). 

[0152] To guarantee successful transmission, this 
embodiment of the present invention delivers VT(A) in 
addition to VT(S) from the source RNC to the target 
RNC. The target RNC then transmits PDUs in SRB2 
based on VT(A), VT(S) and the HFN parameter trans- 
ferred from the source RNC. An establish and modify 
procedure may then be performed as discussed in con- 
nection with the A.2. embodiment of the invention. 
[0153] The RRC message is transmitted by the AMD 
PDUs from VT(S). If a status PDU indicating that the 
user terminal did not receive the PDUs from VR(R) to 
VT(S)-1 is transmitted from the terminal to the target 
RNC, the target RNC transmits an MRW SUFI message 
to the user terminal in order to move the receiver window 
to VT(S). In order to implement these features, an addi- 
tional trigger for transmitting the MRW SUFI message 
may be used. Consequently, a new C-primitive may be 
implemented along with a new trigger for performing an 
SDU discard with explicit signaling procedure. 
[0154] In accordance with an alternative embodiment, 
the source RNC delivers its HFN value and VT(S) to the 
target RNC (Step B.2.1 . in Figure 11) : and stops trans- 
mitting PDUs to the user terminal prior to SRNS reloca- 
tion. In the RLC of the terminal, the processing of pre- 
vious RRC messages is completed. Therefore, the first 
PDU received after SRNS relocation includes the 
UTRAN Mobility Information message having the VT(S) 



value. 

[0155] In accordance with another embodiment, the 
source RNC delivers its HFN value and VT(S)tothe tar- 
get RNC (process B.2.1 . in Figure 11). The source RNC 

5 then transmits a command to the user terminal to In- 
struct the RLC layer of the user terminal to move Its re- 
ceiving window and to not request re-transmission data. 
The RRC layer of the UTRAN may be used to instruct 
the RLC layer of the source RNC to transmit this con> 

io mand. Remaining steps of the method are similar to the 
embodiment discussed immediately above, however 
this embodiment may be implemented to remove RRC 
messages before the SRNS is relocated and for solving 
the re-transmission problem. 

[0156] In any one or more of the B.2. embodiments 
discussed above, an optional step of including a data 
start indicator in the first PDU transmitted by the target 
RNC to the user terminal may be performed. The data 
start indicator may be the same type transmitted in the 
20 RRC message transmitted from the target RNC though 
SRB1 in accordance with the embodiment previously 
discussed. 

[0157] The following example applies: the RLC PDU 
corresponding to the sequence number of VT(S)-1 may 
25 not be correctly received. The next RLC PDU transmit- 
ted by the target RNC right after the relocation proce- 
dure is performed may include the data start indicator 

B.3. Do Not Send UTRAN Mobility Information on SRB2 



[01 58] Relocation . From embodiments B.1 . and B.2., 
it is clear that the transmission of an RRC message on 
SRB2 may be problematic in some respects. In this B. 
3 embodiment, embodiment A.1 or A.2 may be imple- 
mented without the transmission of UTRAN Mobility In- 
formation on SRB2. 

[0159] The embodiments discussed above are all 
preferably performed before or during transmission of 
UTRAN Mobility Information (Case I) or a CellAJRA Up- 
date Confirm message (Case II). That is, either type of 
message can be received by the user terminal when the 
A and B embodiments of the invention are performed. 
Even though the user terminal may receive downlink 
RRC messages correctly from the UTRAN, certain sit- 
uations may arise which will prevent the target RNC 
from receiving a UTRAN Mobility Information Confirm 
message from the user terminal in both-Cases I and II. 
This confirmation message may be sent in SRB2 (AM/ 
DCCH), but because the VT(S) in the user terminal and 
the VR(R) in the target RNC are usually different (e.g., 
VT<S) * 0, VR(R) = 0) a need may arise to synchronize 
the HFN and SN values in the user terminal and target 
RNC before the UTRAN Mobility Information Confirm 
message is transmitted. The following embodiments of 
the present invention address this problem 
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C.1. User Terminal Receives Downlink RRC Message 
on SRB1 (UM/CCCH) . 

[0160] Referring to Figure 12, in this case only the 
downlink HFN of SRB1 is synchronized. Before trans- 5 
mission of an uplink RRC message (i.e., an RRC mes- 
sage from the terminal to the target RNC), both the tar- 
get RNC and the user terminal should perform opera- 
tions 110 and 120 which respectively establish and re- 
establish SRB2. This includes setting both the target 
RNC and user terminal to the same HFN value. These 
steps may be accomplished by ciphering a message 
transmitted from the user terminal to the target RNC with 
an incremented HFN value {e.g., the current value of 
HFN + 1) as is performed in the case of a combined 
Hard Handover and SRNS relocation. Another possible 
value for HFN is MAX(UL HFN of SRB2 I DL HFN of 
SRB2) + 1 . Any value can be used as long as the user 
terminal and target RNC have the same HFN. 

C.2. User Terminal Receives Downlink RRC Message 
on SRB2 (AM/DCCH) with a RESET Procedure. 

[0161] If the user terminal receives a downlink RRC 
message on SRB2 and the embodiment of B.1 is per- 
formed, SRB2 does not have to be established/re-es- 
tablished after the message is received. During the Re- 
set procedure, the HFN values in the user terminal and 
target RNC (UL and DL HFNs) are synchronized and 
the user terminal sends an UL RRC message to the tar- 
get RRC without re-establishing SRB2. After transmis- 
sion of the UL RRC message, boththe user terminal and 
the UTRAN should establish/re-estabtish the SRBs (ex- 
cept SRB2) and RBs with the START value included in 
the UTRAN Mobility Information Confirm message 

C.3. User Terminal Receives Downlink RRC massage 
on SRB2 (AM/DCCH) with an SDU Discard with Explicit 
Signaling Procedure. 

[0162] If the user terminal receives a DL RRC mes- 
sage on SRB2 and the embodiment of B.2. is performed, 
only the DL HFN of SRB2 is synchronized. Since the UL 
H FN is not synchronized, SRB2 must be established/re- 
established in both the user terminal and the UTRAN. 
The rest of the procedure is the same as in C.1 . except 
that DL SRB1 needs to be re-established. 
[0163] In one or more of the C embodiments dis- 
cussed above, after transmission of the UL RRC mes- 
sage, both the user terminal and the UTRAN may re- 
establish/establish the SRBs (except SRB2) and RBs 
with a START value which corresponds to an initial value 
of the HFN. This may be accomplished by transmitting 
the START value in the RRC message, i.e., the UTRAN 
Mobility Information Confirm message. As an example, 
the START value may be stored in the upper 20 bits of 
the HFN. If the size of the HFN exceeds 20 bits, the re- 
maining bits may be initialized to 0. The START value 



may correspond to a predetermined value (which may, 
for example, be defined in accordance with the stand- 
ards developed by the 3<2PP) and may be managed by 
a ciphering module of the terminal. The "START value 
may be disconnected from the terminal or may be up- 
dated according to a change in the HFN value during 
connection. 

[0164] It should be noted that the embodiment of C. 
1 , may be applied for all cases. Though the user terminal 
receives a DL RRC message on SRB2 with a Reset Pro- 
cedure in C2, the re- establishment of SRB2 does not 
create problems in normal operation. In this case, the 
HFNs may be updated a maximum of two times, 
[0165] In the foregoing embodiments, it may be pref- 
erable not to include an IE (Information element) "RLC 
re-establishment indicator (RB2, RB3, and RB4)" in the 
Cell Update Confirm message. If it is included, the user 
terminal may re-establish SRB2, SRB3, andSRB 4 and 
set their HFN values to~a START value included irTthe" 
latest transmitted Cell Update message. Since the user 
terminal SRB2 is re-established with this START value, 
the UTRAN may not be able to receive a UTRAN Mo- 
bility Information Confirm message (UTRAN SRB2 is 
established with either HFN+1 or MAX(UL HFN of SRB2 
I DL HFN of SRB2) + 1). It is further noted that these 
embodiments may correspond to all of the SRBs and 
common RBs. However, for SRB2, because the HFN 
value is synchronized before the UTRAN Mobility Infor- 
mation Confirm message is transmitted, it may not be 
necessary to reset the HFN value. Also, while the initial 
value for VT(US) has been illustratively discussed as 
corresponding to zero, those skilled in the art can ap- 
preciate that other initial values may be used for this or 
any other state variable discussed herein. 
(0166] The embodiments of the present invention 
have been adopted in the following 3GPP Technical 
Specifications which are incorporated by reference 
herein: Technical Specification TS 25.303 v3.10.0, 
Technical Specification TS 25.303 V3.11.0, Technical 
Specification TS 25.322 V3.9.0, Technical Specification 
TS 25.331 V3.9.0, Technical Specification TS 25.331 
V3.10.0, and all updates, revisions, and modification 
thereto. 

[0167] A re-statement of various embodiments of the 
invention as indicated above may be provided as fol- 
lows. 

Combined CeiVURA Update and SRNS Relocation 
(Lossless Radio Bearers) 

[0168] The method of the present invention may be 
initiated by the source RNC deciding to perform an 
SRNS relocation. Steps of this method, which have 
been previously discussed and are re-stated below, are 
shown in greater detail in Fig. 13. Here, Case 1 repre- 
sents the situation where the user equipment (UE) is not 
involved and Case 2 represents the situation wherein 
the UE is involved and a Combined Cell/URA update 
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and SRNS relocation is performed. 
[0169] In an initial step, an RANAP Relocation Com- 
mand is received by the source RNC from the CN, indi- 
cating the RABs to be released and the RABs that are 
subject to data forwarding. Lossless SRNS relocation 
may be configured for RABs that are subject to data for- 
warding. The PDCP layer supports PDCP sequence 
numbering when lossless SRNS relocation is support- 
ed. 

[0170] For the affected radio bearers, the RLC entity 
is stopped and the PDCP sequence numbers are re- 
trieved by the RRC. The PDCP send and receive se- 
quence numbers are then transferred in the RNSAP Re- 
location Commit message from the source to the target 
RNC for RABs that support lossless SRNS relocation. 
The target RNC becomes the serving RNC when the 
RANAP Relocation Detect message is sent. 
[0171] The target RNC then sends a UTRAN MOBIL- 
ITY INFORMATION (Case 1) message on SRBJM <UM/ ~ 
DCCH) or SRB#2 (AM/DCCH), or a CELL/URA UP- 
DATE CONFIRM message (Case 2) on SRB#1 (UM/ 
DCCH), which configures the UE with the new U-RNTI 
and indicates the uplink receive PDCP sequence 
number for each radio bearer configured to support loss- 
less SRNS relocation. 

[0172] If SRB#1 is to be used, the target RNC estab- 
lishes the UM RLC entity for SRB#1 and the DL HFN 
and/or the VT(US) values are set to the values in the 
RRC container. In performing this step, the DL HFN val- 
ue may be set to the current DL HFN value incremented 
by one. In the UM RLC entity, a "Special LI" is preferably 
used to indicate that an RLC SDU begins in the begin- 
ning of an RLC PDU. 

[0173] If SRB#2 is to be used, the target RNC estab- 
lishes the AM RLC entity and the DL and UL HFN values 
are set to the current DL and UL HFN values. Before 
sending a UTRAN MOBILITY INFORMATION mes- 
sage, the transmitting side of the AM RLC entity initiates 
RLC RESET procedure to synchroni2e the HFN values 
between the UTRAN and UE. 

[0174] Upon reception by the UE of the message, the 
UE compares the uplink receive PDCP sequence 
number with the UE uplink send PDCP sequence 
number. If this confirms that PDCP SDUs were success- 
fully transferred before the start of relocation (i.e., al- 
ready received by the source RNC), then these are dis- 
carded by the UE. The UE re-initiali2es the PDCP head- 
er compression entities of the radio bearers configured 
to use a header compression protocol. The RLC (e.g.,. 
AM RLC) entity for SRB#2 is (re-)established both on 
the UTRAN and UE sides, and their HFN values are set 
to VALUE incremented by one. (Here, VALUE may be 
defined as either the current HFN value or 

MBKIfinNhiffSftBSRB2 
[0175] If the UE has successfully configured itself, it 



shall send a UTRAN MOBILITY INFORMATION CON- 
FIRM message (Case 1 and Case 2). These messages 
preferably contain the START values and the downlink 
receive PDCP sequence number for each radio bearer 

5 configured to support lossless SRNS relocation. 

[0176] Upon reception and acknowledgment by the 
UTRAN of the message, the UTRAN compares the 
downlink receive PDCP sequence number with the 
downlink send PDCP sequence number. The UTRAN 

10 initializes the PDCP header compression entities of the 
radio bearers configured to use a header compression 
protocol. The RLC entities for affected radio bearers 
(other than SRB#2) are (re-)established both on the 
UTRAN and UE side. The HFN values for each RB are 

15 preferably set to the START value in the message for 
the corresponding CN domain, and all the data buffers 
are flushed. 

[0177] In case of failure, the UE shall send a UTRAN 
— MOBILITY INFORMATION FAILURE message {Case 1 
*o and Case 2). 

[0178] Upon reception of the UTRAN MOBILITY IN- 
FORMATION CONFIRM/FAILURE (Case 1 and Case 
2), the relocation procedure ends. 

Combined CelVURA Update and SRNS Relocation 
(Seamless Radio Bearers) 

[0179] The method of the present invention may be 
initiated by the source RNC deciding to perform an 

so SRNS relocation. Steps of this method, which have 
been previously discussed and are re-stated below, are 
shown in greater detail in Fig. 14. Here, Case 1 repre- 
sents the situation where the user equipment (UE) is not 
involved and Case 2 represents the situation wherein 

35 the UE is involved and a Combined Cell/URA update 
end SRNS relocation is performed. 
[0180] In an initial step, an RANAP Relocation Com- 
mand is received by the source RNC from the CN, indi- 
cating the RABs to be released. The source RNC con- 

40 tinues the downlink data transmission on radio bearers 
supporting seamless SRNS relocation until the target 
RNC becomes the serving RNC. The target RNC be- 
comes the serving RNC when the RANAP Relocation 
Detect message is sent. 

<* [0181] The target RNC sends a UTRAN MOBILITY 
INFORMATION message (Case 1) on SFIB#1 (UM/ 
DCCH) or SRB#2 (AM/DCCH), or a CELL/URA UP- 
DATE CONFIRM message (case 2) on SRB#1 (UM/ 
DCCH), which configures the UE with the new U-RNTI. 

50 [01 82] If SRBfM is to be used, the target RNC estab- 
lishes the UM RLC entity and the DL HFN value is set 
to the current DL HFN value incremented by one. In the 
UM RLC entity, a "Special LP is preferably used to indi- 
cate that an RLC SDU begins in the beginning of an RLC 

55 PDU. 

[01 83] If SRB#2 is to be used, the target RNC estab- 
lishes the AM RLC entity and the DL and UL HFN values 
are set to the current DL and UL HFN values. Before 
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sending a UTRAN MOBILITY INFORMATION mes- 
sage, the transmitting side of the AM RLC entity initiates 
RLC RESET procedure to synchronize the HFN values 
between the UTRAN and UE. 
[01 84] Upon reception by the UE of the message, the 
RLC entity lor SRB#2 is (re-)established both on the 
UTRAN and UE sides, and their HFN values are set to 
VALUE incremented by one. (Here, VALUE may be de- 
fined as either the current HFN value or MAX (UL HFN 
of SRB2 I DL HFN of SRB2)). 
[0185] If the UE has successfully configured itself, it 
shall send a UTRAN MOBILITY INFORMATION CON- 
FIRM message (Case 1 and Case 2). These message 
preferably contain the START values (to be used in in- 
tegrity protection and in ciphering on radio bearers using 
UM and AM RLC). 

[0186] Upon reception and acknowledgment by the 
UTRAN of the message, the UTRAN initializes and the 
UE re-initializes the PDCP header compression entities - 
of the radio bearers configured to use a header com- 
pression protocol. The RLC entities for affected radio 
bearers (other than SRB#2) are (re-)established both on 
the UTRAN and UE side. The HFN values for each RB 
are preferably set to the START value in the message 
for the corresponding CN domain and all the data buff- 
ers are flushed. In case of failure, the UE shall send a 
UTRAN MOBILITY INFORMATION FAILURE message 
(Case 1 and Case 2). Upon reception of the UTRAN 
MOBILITY INFORMATION CONFIRM/FAILURE mes- 
sage (Case 1 and Case 2), the relocation procedure 
ends. 

[0187] In the foregoing embodiments, to initiate the 
method the UTRAN may transmit a UTRAN MOBILITY 
INFORMATION message to the UE on the downlink 
DCCH using AM or UM RLC. In the case of SRNS relo- 
cation, the message may be sent using UM RLC only. 

Signaling Radio Bearer si RRC Connection Mobility 
Procedures Cell and URA Update Procedures 

[0188] When an RRC message is transmitted in DL 
on DCCH or CCCH or SHCCH using RLC UM, RRC will 
preferably indicate to the RLC that a special RLC length 
indicator should be used. The UE may assume that this 
indication has been given. The special length indicator 
indicates that an RLC SDU begins in the beginning of 
an RLC PDU. 

[0189] Reception of a CELL UPDATE/URA UPDATE 
message by the UTRAN based on such a special length 
indicator will now be discussed in accordance with one 
embodiment of the present invention. When the UTRAN 
receives a CELL UPDATEAJRA UPDATE message, the 
UTRAN: 

1> in the case where the procedure was triggered 
by reception of a CELL UPDATE: 

2> if SRNS relocation was performed: 



3> transmit e CELL UPDATE CONf IRM 
message on the downlink DCCH 

2> otherwise: 

5 

3> update the START value for each CN 
domain as maintained in UTRAN with 
"START in the IE "START list" for theCN 
domain as indicated by "CN domain iden- 
10 tity" in the IE "START list"; 

3> if this procedure was triggered while the 
UE was not in CELL_DCH state, then for 
each CN domain as indicated by "CN do- 
« main identity" in the IE "START list"; 

4> set the 20 MSB of the MAC-d HFN 
with the corresponding START value 
in the IE "START list";- - 

so 

A> set the remaining LSB of the MAC- 
d HFN to zero. 

3> transmit a CELL UPDATE CONFIRM 
25 message on the downlink DCCH or option- 

ally on the CCCH but only if ciphering is not 
required; and 

3> optionally include the IE "RLC re-estab- 
30 Hsh indicator (RB5 and upwards)" to re- 

quest an RLC re-establishment in the UE, 
in which case the corresponding RLC enti- 
ties should also be re-established in 
UTRAN; or 

$5 

1> in the case the procedure was triggered by re- 
ception of a URA UPDATE: 

2> if SRNS relocation was performed: 

40 

3> transmit a URA UPDATE CONFIRM 
message on the downlink DCCH 

2> otherwise: 

45 

3> transmit a URA UPDATE CONFIRM 
message on the downlink CCCH or DCCH 

2> include the IE "URA identity" in the URA UP- 
50 DATE CONFIRM message in a cell where mul- 

tiple URA identifiers are broadcast, or 

t > initiate an RRC connection release procedure by 
transmitting an RRC CONNECTION RELEASE 
55 message on the downlink CCCH. In particular, the 
UTRAN should: 

2> if the CELL UPDATE message was sent be- 
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cause of an unrecoverable error in RB2, RB3, 
or RB4: 

3> initiate an RRC connection release pro* 
cedure by transmitting an RRC CONN€C- 
TION RELEASE message onthe downlink 
CCCH. 

Reception of CELL UPDATE CONFIRM/ URA UPDATE 
CONFIRM Message by the UE 

[0190] When the UE receives a<^ELL UPDATE CON- 
FIRM/URA UPDATE CONFIRM message; and 

if the message is received on the CCCH and IE 
"U-RNTI" is present and has the same value as the 
variable U_RNTI; or 

•_. if the message is.received.on DCCH; 

the UE may: 

• if the CELL UPDATE CONFIRM message includes 
the IE "RLC re-establish indicator (RB2, RB3, and 
RB4)'; 

re-establish the RLC entities for signaling radio 
bearer RB2, signaling radio bearer RB3 and sign- 
aling radio bearer RB4 (if established); 

if the value of the IE "Status" in the variable 
CIPH£RING_STATUS of the CN domain stored in 
the variable 
LATEST_CONFIGURED_CN_DOMAIN is set to 
"Started"; 

- set the HFN values for AM RLC entities with RB 
identity 2, RB identity 3 and RB identity 4 (if estab- 
lished) equal to the START value included in the lat- 
est transmitted CELL UPDATE message fortheCN 
domain stored in the variable 
LAT£ST_CONFIGU RED_CN_DOMAIN; 

[0191] The foregoing embodiments and advantages 
are merely exemplary and are not to be construed as 
limiting the present invention. The present teaching can 
be readily applied to other types of apparatuses. The 
description of the present invention is intended to be il- 
lustrative, and not to limit the scope of the claims. Many 
alternatives, modifications, and variations will be appar- 
ent to those skilled in the art. In the claims, means-plus- 
function clauses are intended to cover the structures de- 
scribed herein as performing the recited function and not 
only structural equivalents but also equivalent struc- 
tures. 



Claims 

1 . A method for performing SRNS relocation, compris- 
ing: 

5 

receiving in a target RNC radio resource infor- 
mation from a source FINC, said radio resource 
information including a ciphering parameter; 
modifying the ciphering parameter to coincide 

10 with a deciphering parameter of a user terminal, 

said deciphering parameter corresponding to 
one the user terminal uses when out-of-se- 
quence data is received; 
ciphering a data unit based on the modified ci- 

15 phering parameter; and 

transmitting the ciphered data unit from the tar- 
get RNC to the user terminal. 

2. The method of claim 1 , wherein the target RNC and - 
?o the user terminal are operating in UM mode. 

3. The method of claim 2, further comprising: 
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transmitting the ciphered data unit over a serv- 
ing radio bearer SRB1. 

4. The method of claim 2, further comprising: 

transmitting the ciphered data unit over a UM 
DCCH channel. 

5. The method of claim 1, wherein said out-of-se- 
quence data includes data having a transmission 
sequence number which does not consecutively fol- 
low a transmission sequence number of a last PDU 
transmitted from the source RNC to the user termi- 
nal. 

6. The method of claim 1 , wherein the ciphering pa- 
rameter and said deciphering parameter are HFN 
parameters. 

7. The method of claim 1 , wherein said modifying step 
includes: 

adjusting an HFN value of the ciphering param- 
eter to equal an HFN value of said deciphering 
parameter when said out-of -sequence data is 
received. 

The method of claim 7, wherein said adjusting step 
includes: 

incrementing the HFN value of the ciphering 
parameter to equal an incremented value of 
said deciphering parameter. 



9. The method of claim 1, wherein the transmitting 
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step includes: dicator indicates that the data unit is not included 

as part of an SDU previously transmitted to the user 

transmitting a data start indicator with the ci- terminal, 
phered data unit. 

s 20. A method tor performing SRNS relocation, compris- 

10. The method of claim 9, wherein said data start in- ing: 
dicator indicates that the ciphered data unit is not 

included as part of an SDU previously transmitted resetting transmission information of a target 

to the user terminal. RNC; and 

10 transmitting a message instructing a user ter- 

11. A method for performing SRNS relocation, compris- minal to reset reception information to values 
ing: which coincide with said reset transmission in- 
formation of the target RNC. 

receiving in a target RNC radio resource infor- 
mation from a source RNC; and 15 21 . The method of claim 20, wherein said resetting step 
transmitting a data uni\ from the target RNC to includes resetting a transmission sequence number 
a user terminal, said data unit including a trans- to an initial value in the target RNC, and wherein 
mission sequence number which consecutively said reset reception information includes a trans- 
follows a transmission sequence number of a mission sequence number of a next-expected data 
data unit last transmitted from the source RNC so unit set to said initial value, 
to the user terminal. 

22. The method of claim-20, wherein said resetting step 

12. The method of claim 11 , further comprising: includes resetting a state variable to en initial value 

in the target RNC, and wherein said message in- 
ciphering the data unit before said transmitting 25 eludes information instructing the user terminal to 
step. be set to said state variable. 



13. The method of claim 12, wherein the ciphering step 
includes: 

30 

ciphering the data unit with a same ciphering 
parameter the user terminal used to decipher a 
data unit transmitted from the source RNC to 
the user terminal. 

35 

14. The method of claim 13, wherein said same cipher- 
ing parameter includes a same HFN value. 

15. The method of claim 11, wherein the target RNC 
and the user terminal are operating in UM mode. <o 

16. The method of claim 11 . further comprising: 



17. The method of claim 11 , further comprising: 

transmitting the data unit over a serving radio 
bearer SRB1. so 



23. The method of claim 50, wherein said message is 
an unciphered message. 

24. The method of claim 20, further comprising: 

receiving a message from the user terminal in- 
dicating that the user terminal has reset said 
reception information. 

25. The method of claim 20, wherein said resetting step 
includes setting a ciphering parameter to an initial 
value, and wherein said reset reception information 
includes a deciphering parameter which coincides 
with the initial value of said ciphering parameter. 

26. The method of claim 25, wherein said ciphering pa- 
rameter and said deciphering parameter include a 
same HFN value. 

27. The method of claim 20, wherein said resetting step 
includes flushing SDUs in the target RNC and 
wherein said message instructs the user terminal to 
flush SOUs. 



transmitting the data unit over a UM DCCH 
channel. 45 



18. The method of claim 11, wherein the transmitting 28. The method of claim 20, further comprising: 
step includes: 

transmitting a data unit from the target RNC to 
transmitting a data start indicator with the data ss the user terminal over a serving radio bearer 

unit. SRB2. 

19. The method of claim 18, wherein said data start in- 29. The method of claim 20, wherein the target RNC 
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and the user terminal are operating in AM mode. 

30. The method of claim 29, further comprising: 

transmitting a ciphering parameter and trans- 
mission sequence number information from a 
source RNC to the target RNC, wherein said 
ciphering parameter coincides with a decipher- 
ing parameter used in the user terminal and a 
ciphering parameter the source RNC used to 
transmit a data unit to the user terminal, end 
wherein said transmission sequence number 
information is indicative of a next-expected 
transmission sequence number in the user ter- 
minal. 

31. The method of claim 20, further comprising: 

transmitting a data unit from the target RNC to 
the user terminal, said data unit including a data 
start indicator indicating that the data unit is not 
included as part of an SDU previously transmit- 
ted to the user terminal. 

32. The method of claim 20, further comprising: 

transmitting a data unit from the target RNC to 
the user terminal over an AM DCCH channel. 

33. A method for performing SRNS relocation, compris- 
ing: 

delivering radio resource information from a 
source RNC to a target RNC in a UTRAN. said 
radio resource information including: 

a) a ciphering parameter the source RNC 
used to transmit PDUs to a user terminal, 
and 

b) a transmission sequence number corre- 
sponding to one of a next PDU to be trans- 
mitted by the source RNC to a user termi- 
nal or a last PDU that was transmitted from 
the source RNC to the user terminal; 

generating a PDU/RRC message based on 
said transmission sequence number; 
ciphering the PDU/RRC message with said ci- 
phering parameter; and 
transmitting the ciphered message from the tar- 
get RNC to a user terminal. 

34. The method of claim 6, wherein the target RNC and 
the user terminal are operating in AM RLC mode. 

35. A method for performing a relocation procedure in 
a communications system, said communications 
system including a transmitter and a receiver; said 



method comprising: 

initializing the transmitter to communicate with 
the receiver, said initializing step including set- 
5 ting a transmission sequence number to a first 

value and setting a deciphering parameter to a 
second value; 

transmitting a PDU including said initial se- 
quence number and said deciphering parame- 
J0 ter from the transmitter to the receiver; 

determining, in the receiver, that the initial se- 
quence number in the PDU does not equal a 
next sequence number expected by the receiv- 
er; 

'5 setting a deciphering parameter in the receiver 

to the second value; and 
deciphering the PDU. 

36. "A transmission unit, comprising: 

20 

a target RNC which receives radio resource in- 
formation from a source RNC, said radio re- 
source information including a ciphering pa- 
rameter; and 

*5 a processor which modifies the ciphering pa- 

rameter to coincide with a deciphering param- 
eter of a user terminal, and which ciphers a data 
unit based on the modified ciphering parame- 
ter; and 

30 a transmitter which transmits the ciphered data 

unit from the target RNC to the user terminal, 
wherein said deciphering parameter corre- 
sponding to one the user terminal uses when 
out-of-sequence data is received. 

35 

37. The transmission unit of claim 36, wherein the tar- 
get RNC and the user terminal are operating in UM 
mode. 

*o 38. The transmission unit of claim 37, wherein the 
transmitter transmits the ciphered data unit over a 
serving radio bearer SRB1 . 

39. The transmission unit of claim 36, wherein the 
45 transmitter transmits the ciphered data unit over a 

UM DCCH channel. 

40. The transmission unit of claim 36, wherein said out- 
of-sequence data includes data having a transmis- 

50 sion sequence number which does not consecutive- 
ly follow a transmission sequence number of a last 
PDU transmitted from the source RNC to the user 
terminal. 

55 41. The transmission unit of claim 36, wherein the ci- 
phering parameter endsaid deciphering parameter 
are Hf N parameters. 
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42. The transmission unit of claim 36, wherein said 
processor adjusts an HFN value of the ciphering pa- 
rameter to equal an HFN value of said deciphering 
parameter when said out-of -sequence data is re- 
ceived. 

43. The transmission unit of claim 42, wherein said 
processor increments the HFN value of the cipher- 
ing parameter to equal an incremented value of said 
deciphering parameter. 

44. The transmission unit of claim 36, wherein the 
transmitter transmits a data start indicator with the 
ciphered data unit. 

45. The transmission unit of claim 44, wherein said data 
start indicator indicates that the ciphered data unit 
is not included as part of an SOU previously trans- 
mitted to the user terminal. 

46. A transmission unit, comprising: 

a target RNC which receives radio resource in- 
formation from a source RNC; and 
a transmitter which transmits a data unit from 
the target RNC to a user terminal, said data unit 
including a transmission sequence number 
which consecutively follows a transmission se- 
quence number of a data unit last transmitted 
from the source RNC to the user terminal. 

47. The transmission unit of claim 46, further compris- 
ing: 

a processor which ciphers the data unit before 
transmission. 

48. The transmission unit of claim 47, wherein the proc- 
essor ciphers the data unit with a same ciphering 
parameter the user terminal used to decipher a data 
unit transmitted from the source RNC to the user 
terminal. 

49. The transmission unit of claim 48, wherein said 
same ciphering parameter includes a same HFN 
value. 

50. The transmission unit of claim 46, wherein the tar- 
get RNC and the user terminal are operating in UM 
mode. 

51. The transmission unit of claim 46, wherein the 
transmitter transmits the data unit over a UM DCCH 
channel. 

52. The transmission unit of claim 46, wherein the 
transmitter transmits the data unit over a serving ra- 
dio bearer SRB1. 



53. The transmission unit of claim 46, wherein the 
transmitter transmits a data start indicator with the 
data unit. 

5 54. The transmission unit of claim 53, wherein said data 

start indicator indicates that the data unit is not in- 
cluded as part of an SDU previously transmitted to 
the user terminal. 

10 55. A method for performing SRNS relocation, compris- 
ing: 

receiving in a target RNC an RNSAP Reloca- 
tion Commit message from a source RNC, said 
w message including an HFN ciphering parame- 

ter; 

modifying the HFN ciphering parameter to co- 
incide with an HFN parameter of a UE, said UE 
HFN parameter conesponding to one the UE 

6 uses when an out-of-sequence PDCP se- 
quence number is received; 

ciphering an RLC PDU based on the modified 
HFN ciphering parameter; and 
transmitting the ciphered RLC PDUE from the 
25 target RNC to the UE. 

56. The method of claim 55, wherein the target RNC 
and the UER are operating in UM mode. 

30 57. The method of claim 56, further comprising: 

transmitting the ciphered RLC PDU over a serv- 
ing radio bearer SRB1 . 

35 58. The method of claim 56, further comprising: 

transmitting the ciphered RLC PDU over a UM 
DCCH channel. 

*o 59. The method of claim 55, wherein said out-of-se- 
quence PDCP sequence number does not consec- 
utively follow a PDCP sequence number of a last 
RLC PDU transmitted from the source RNC to the 
UE. 

45 

60. The method of claim 55, wherein said modifying 
step includes: 

adjusting a value of the HFN ciphering param- 
50 eter to equal a value of said UE H FN parameter 

when said out-of-sequence PDCP sequence 
number is received. 

61 . The method of claim 60, wherein said adjusting step 
55 includes: 

incrementing the HFN ciphering parameter to 
equal an incremented value of said UE HFNpa- 
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rameter. 

62. The method of claim 65, wherein the transmitting 
step includes: 

transmitting a START value with the ciphered 
RLC PDU, said START value indicating that the 
ciphered RLC PDU is not included as part of an 
SDU previously transmitted to the UE. 

63. A method of sending information in a mobile radio 
communication system comprising: 

receiving the information including the numbers 
related to a ciphering sequence number and 
the state variable of a radio link control entity of 
a radio network controller which was previously 
a serving radio network controller of a terminal; 
establishing a radio link control entity for send- 
ing information to said terminal; 
setting the state variable of a radio link control 
entity synchronized with said received state 
variable; and 

sending a data unit of said information starting 
with the state variable to said terminal. 

64. A method of claim 63, further comprising: 

setting an indicator indicates that a service data 
unit contains the informationbegins in the be- 
ginning of a data unit of said radio link control 
entity. 

65. A method of claim 63, wherein, one of the state var- 
iables of a radio link control entity is the sequence 
number of the RLC PDU to be transmitted next time. 

66. A method of claim 65, wherein, one of the state var- 
iables of a radio link control entity is the most prior 
sequence number of the RLC PDU to be retrans- 
mitted. 



10 



15 



20 



25 



30 



35 



40 



network controller; setting a length indicator in- 
dicates that an RLC SDU begins in the begin- 
ning of an RLC PDU; and 
sending information ciphered with the ciphering 
sequence number through said radio link con- 
trol entity to said terminal. 

69. A method of sending information in mobile radio 
communication system comprising: 

receiving down link radio resource control mes- 
sage on signalling radio bearer; 
checking the serving radio network controller 
changes; 

changing hyper frame number value for anoth- 
er signalling radio bearer; and 
transmitting up link radio resource control mes- 
sage ciphered with a number from the changed 
hyper frame number. 

70. A method of claim 6g, further comprising: 

sending a predetermined value for the hyper 
frame number to the serving radio networkcon- 
troller; and 

establishing other signalling radio bearers with 
said predetermined value. 

71. A method of claim 70, wherein said predetermined 
value is the start value of the hyper frame number. 

72. A method of claim 69, wherein the changed hyper 
frame number value is current value + 1 . 

73. A method of claim 69, wherein the changed hyper 
frame number value is the larger value between 
those of uplink and downlink + 1 



67. A method of claim 64, further comprising; sending 
an instruction for moving the receiving window to 
said terminal. 
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68. A method of sending information in a mobile radio 
communication system comprising: 

receiving the instruction which instructs to be- 
come the serving radio network controller of a 
terminal from core network with the information 
including the numbers related to a ciphering se- 
quence number; 

establishing a radio link control entity for signal- 
ling control information to said terminal; 
setting the ciphering sequence number accord- 
ing to said numbers received from other radio 
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